Linux

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. ...

Two years ago, I’ve used multiple Intel X710-DA4 NICs to built an EVPN Setup for my company level66.network. Whilst most of the connections to other peers worked quite well, I’ve had a few links which showed some strange issues. Most commonly the links were reported as flapping from the other peers or they just reported packetloss on their end. After quite some time of troubleshooting, switching optics and using different ports we found the solution. With the default configuration of the Linux driver, the NIC seems to sent out some (maybe malformed) LLDP messages causing issues with some specific networking gear. We were not able to narrow it down to a specific vendor, though. These messages are directly generated on the NIC and are therefore not shown in a tcpdump. That’s why we were not aware of them. ...