Blog

An Opengear OM2200 console server was stuck in a boot loop and could no longer be reached, neither via the web interface nor via SSH. Opengear support provided a recovery image which is booted from a USB drive and restores the device to factory defaults. This post summarizes the procedure. Requirements A USB flash drive with at least 2 GB. It will be erased completely. A computer that can run balenaEtcher The OM2200 recovery image from Opengear Create the Recovery USB Drive Extract the downloaded ZIP file. It contains two files; the smaller .bmap file can be ignored, as balenaEtcher doesn’t need it. Open balenaEtcher and select Flash from file. Select core-image-recovery-ogpuma-1.0.0-production-signed.wic. Select the USB drive as target and double-check that it is the correct one. Click Flash! and wait until flashing and validation have finished. Depending on the PC and the drive, this takes a few minutes. Safely remove the USB drive. Recover the OM2200 Remove power from the OM2200. Insert the recovery USB drive into one of the USB ports below the RJ45 console ports on the front of the device. Locate the ERASE button on the front. Reapply power and immediately press and hold the ERASE button with a paperclip or similar. Keep holding it for about 20 seconds. The power LED comes on after roughly 8 seconds and goes out around the 20-second mark. Release the button when it goes out. The recovery now starts automatically. The LEDs may blink and cycle several times, which is expected. Don’t interrupt the power and don’t remove the USB drive. The device should be back at factory defaults about 4 minutes and 20 seconds after releasing the ERASE button. Remove the USB drive once the recovery has finished. After the Recovery On the local console port a login prompt appears eventually. Without a console connection, the device is reachable on its default NET1 address: ...

We recently bought two used Rittal PDUs (7979.216) which were still configured by the previous owner. Neither the web interface nor SSH was accessible, as the admin credentials were unknown and the default credentials didn’t work. Power-cycling the device or pressing the reset button once did not change anything. I asked the Rittal technical support how to get the devices back to factory defaults and received a pretty simple answer. ...

While building our new network backbone, we tested five newly constructed darkfibre routes (and the DWDM systems on top of them) before putting anything into production. The carrier supplied measurement protocols for every route, and in all cases they looked clean. Only two of the five routes worked flawlessly right away. The other three had issues: Two routes with incomplete cabling in the data centers. The fibers simply ended after about 170 meters inside the Meet-Me-Room, because the last patching hadn’t been done. One route with excessive attenuation on a single fiber. After cleaning the connectors, the fiber was back within spec. None of this was visible in the carrier’s protocols. ...

I had a problem: I needed to detect DDoS attacks in a network and react to them automatically. I looked at the tools that were available, but none of them solved it for me. Especially the escalation, and changing the mitigation as an attack evolves, could not be adapted in most solutions. So I decided to build my own solution: flowwler. If your network could talk, it would say: “I can see the attack. I just need help reacting to it.” That is the idea behind flowwler. Its design goal is simple logic, quick decisions and clear escalation levels, without overloading the operator. ...

For our new network backbone the configuration of every switch is built from NetBox. Nobody logs in to a switch to change something by hand. This post describes how the pieces fit together. The NetBox Model We keep the model deliberately small: Devices Interfaces VRFs VLAN groups VLANs For the VXLANs we do not use L2VPN objects. A VLAN in NetBox is the L2 segment, and its VNI is derived from the object ID: ...

We are building a new network backbone for Medialine Group. The first big milestone is done: within one week, we deployed 192x 100G and 384x 10/25G ports. Sites The backbone connects three Frankfurt locations in a redundant ring: Equinix FR5 (rack) Telehouse Frankfurt (rack) Equinix FR2 (new cage) ITENOS Frankfurt 1 is currently still the main site. In the future it will only be used for backups, and until then it is connected with 2x 100G via redundant cross-connects. ...

We have multiple Opengear console-servers in the field which are using LTE as the primary connectivity for our out-of-band access. Most of the people would use Opengear Lighthouse to manage and administer their fleet of devices. Due to the rather small amount of devices on our end, we decided to use a more lightweight solution. By using the public IPv6 addresses gathered via LTE (thanks Telekom!) and DynDNS, we are able to connect to the console-servers at any time. As DynDNS is not included with the Opengear Operations Manager, we use a Playbook to update the entries at dynv6 through their Update API on a regular basis. ...

As I use Zammad as the helpdesk-system in my company, I was looking for a way to create alerts in PagerDuty for critical tickets in Zammad. I initially just forwarded the tickets by mail to PagerDuty which worked but was a kind of dirty approach. With the new option of using custom webhooks in Zammad, the integration is a little smoother. On the PagerDuty-side, you need to have a service created. In the service itself, you need to enable the “Events API v2” integration. Make sure to take note of the “Integration Key” as this is needed during the setup in Zammad. ...

I use dynv6.com as a DynDNS Service for me an my customers. During the last installation of the service at a client, I ran into a issue with ddclient not sending the update to dynv6.com. root@zoidberg:~# ddclient --force FAILED: updating zoidberg.ddns.level66.network: Could not connect to dynv6.com. I used the configuration values from the dynv6.com site but it seems they did not be enough. root@gw:~# cat /etc/ddclient.conf # Configuration file for ddclient generated by debconf # # /etc/ddclient.conf protocol=dyndns2 use=if, if=eth0 server=dynv6.com login=none password=asdasdasdiiugofiugoisfugj zoidberg.ddns.level66.network root@gw:~# ddclient -debug --force DEBUG: Reply from 'ip -4 -o addr show dev wwan0 scope global' : DEBUG: ------ DEBUG: 6: eth0 inet 37.80.164.188/29 scope global wwan0\ valid_lft forever preferred_lft forever DEBUG: ------ DEBUG: get_ip: using if, eth0 reports 37.80.164.188 DEBUG: DEBUG: nic_dyndns2_update ------------------- DEBUG: proxy = <undefined> DEBUG: protocol = http DEBUG: server = dynv6.com DEBUG: url = nic/update?<redacted> DEBUG: ip ver = FAILED: updating zoidberg.ddns.level66.network: Could not connect to dynv6.com. After some digging into the debug output of ddclient, I enabled SSL/TLS in the update method and it seems to do the trick. ...

As I work for multiple customers, I First, we need to setup the normal Horizon Agent. Make sure to run the setup with the option to skip the registration to the session broker. VMware-Horizon-Agent.exe /s /v "VDM_SKIP_BROKER_REGISTRATION=1 RDP_CHOICE=1 ADDLOCAL=Core,ClientDriveRedirection,VmwVaudio,PrintRedir,USB,RTAV" VMware-viewagent-direct-connection--y.y.y-xxxxxx.exe /s /v "LISTENPORT=443 MODIFYFIREWALL=1 DISABLE_SSLV3=1"