Blog

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"

A researcher found that the MIC600T-LX inverter has exactly the same hardware as the larger units such as the MIC2000T-LX inverter. As there were no physical differences in the hardware, they dug into the software and were able to find a register in the Modbus protocol used by the inverter that determines the actual mode/output power limit of the specific unit. Interestingly, this mode is not only readable but also writable by the user. ...