Fun.<\/p>\n
So, we have a working DHCP in failover mode, working in the 52 VLANs and everything seems fine. But, I think that all its developers are idiots, as I’ve hit a few really stupid problems.
\n(background information – we’re using the same version on the same hardware, on a freebsd and ubuntu).<\/p>\n
1) When a peer is defined, both sides have to be named in the same way, or it would refuse to link. Seems stupid to me. I tried running dhcpd 4.1, but it had some weird issues too (although I tested it just for a bit, I got a bit mad at the compilation – had to hack some things and to remove the dhcpv6 support).<\/p>\n In short, the failover protocol is crap.<\/p>\n","protected":false},"excerpt":{"rendered":" Fun. So, we have a working DHCP in failover mode, working in the 52 VLANs and everything seems fine. But, I think that all its developers are idiots, as I’ve hit a few really stupid problems. (background information – we’re using the same version on the same hardware, on a freebsd and ubuntu). 1) When […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[75],"class_list":["post-2641","post","type-post","status-publish","format-standard","hentry","category-general","tag-har2009"],"_links":{"self":[{"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2641"}],"version-history":[{"count":0,"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2641\/revisions"}],"wp:attachment":[{"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vasil.ludost.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n2) Again in the peer definition, if peer port and port are the same, it refuses to connect. WTF.
\n3) If both machines’ clocks differ with more 60 seconds, it doesn’t link. Tis is OK, but then one of them crashes with SIGSEGV.
\n4) While in failover mode, you can expect all kinds of weird messages looking like errors, which are actually normal, like:
\n
\ndhcpd: bind update on 87.76.100.23 got ack from SERVER2: xid mismatch.
\ndhcpd: bind update on 87.76.104.41 from SERVER2 rejected: incoming update is less critical than outgoing update
\n<\/code>
\n5) From time to time they might lost connectivity and stay in a weird hanging mode, in which they easily overflow a pool. Most probably the problem is this one<\/a>, but I haven’t seen a solution yet, I think it’s not fixed in 4.1 either. The only way to know that has happened is by doing
\n
\ngrep 'failover peer' \/var\/log\/syslog
\n<\/code>
\nand the last thing at the end is
\n<\/code>
\ndhcpd: failover peer SERVER2: peer moves from normal to communications-interrupted
\n<\/code>
\n(without any commonications-interrupted to normal transition later)<\/p>\n