<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello again -<div class=""><br class=""></div><div class="">a couple of days ago I converted one of my test route-server setups from „dual BIRD-1.6.3“ to „single BIRD-2.0.0“ by simply „merging“ bird6.conf and bird.conf into a single (unified) new bird.conf - also observing the guidelines laid out in <a href="https://gitlab.labs.nic.cz/labs/bird/wikis/transition-notes-to-bird-2" class="">https://gitlab.labs.nic.cz/labs/bird/wikis/transition-notes-to-bird-2</a> . </div><div class=""><br class=""></div><div class="">The results of this simple approach are between weird and stunning:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">I now have a bird process which is consuming 100% of one CPU. It is still talking to me through birdc, but is very sluggish, i.e. bringing up peers or tearing them down takes a long time - you even see states, like „flushing“ in „show proto all XXX“ for quite some time, which you normally don’t even notice, because they are usually <i class="">very transitive</i> :-)<br class=""><br class="">I haven’t gotten deeper into the problem, yet, but there appears to be a loop involving the affected peer’s Export Updates:<br class=""><br class=""> Route change stats: received rejected filtered ignored accepted<br class=""> Import updates: 670962 0 0 0 670962<br class=""> Import withdraws: 216 0 --- 0 216<br class=""><b class=""> Export updates: 317034802 159525749 157509053 --- 0<br class=""></b> Export withdraws: 468 --- --- --- 0<br class=""><br class="">(those numbers are increasing <b class="">fast</b>)<br class=""><br class=""></li><li class="">Some of my peers were/are already MP-BGP capable and so some IPv6 peers now came up with „Hey, you speak IPv4 too? Cool! Here are some 700.000 routes for your, my friend!“, which is totally explicable, yet it surprised my a teeny bit, anyway :-)<br class=""><br class="">It should be made clear in the documentation, that BGP protocol definitions without explicit address-family → „channel“ definitions my eventually (see below) ending up MP-BGP sessions with the above effect!?<br class=""><br class=""></li><li class="">Most surprising: My <i class="">multiple-inheritance</i> approach, using multiple, chained template definitions for my BGP „protocols“/sessions/peers broke in the weirdest way: I now have <i class="">multiple</i> IPv6 and IPv4 channels on some of my protocols with different parameterizations:<br class=""><br class="">bird> <b class="">show protocols all BOGONS6</b><br class="">Name Proto Table State Since Info<br class="">BOGONS6 BGP --- up 17:04:11.929 Established <br class=""> BGP state: Established<br class=""> Neighbor address: 2620:0:6b0::26e5:4207<br class=""> Neighbor AS: 65332<br class=""> Neighbor ID: 38.229.66.20<br class=""> Local capabilities<br class=""> Multiprotocol<br class=""><b class=""> AF announced: ipv4 ipv4 ipv6 ipv6<br class=""></b> Route refresh<br class=""> Graceful restart<br class=""> Restart time: 120<br class=""> AF supported: ipv4 ipv6<br class=""> AF preserved:<br class=""> 4-octet AS numbers<br class=""> ADD-PATH<br class=""> RX: ipv4 ipv6<br class=""> TX: ipv4 ipv6<br class=""> Enhanced refresh<br class=""> Neighbor capabilities<br class=""> Multiprotocol<br class=""> AF announced: ipv6<br class=""> Route refresh<br class=""> 4-octet AS numbers<br class=""> Session: external multihop AS4<br class=""> Source address: 2001:XXXXXXXXXXXX:2c9b<br class=""> Hold timer: 120.187/240<br class=""> Keepalive timer: 2.682/80<br class=""><b class=""> Channel ipv6<br class=""></b> State: UP<br class=""> Table: master6<br class=""> Preference: 100<br class=""> Input filter: <b class="">ACCEPT</b><br class=""> Output filter: REJECT<br class=""> Routes: 0 imported, 0 filtered, 0 exported<br class=""> Route change stats: received rejected filtered ignored accepted<br class=""> Import updates: 0 0 0 0 0<br class=""> Import withdraws: 0 0 --- 0 0<br class=""> Export updates: 49787 0 49787 --- 0<br class=""> Export withdraws: 261 --- --- --- 0<br class=""> BGP Next hop: 2001:XXXXXXXXXXXX:2c9b<br class=""> IGP IPv6 table: master6<br class=""><b class=""> Channel ipv4<br class=""></b> State: DOWN<br class=""> Table: master4<br class=""> Preference: 100<br class=""> Input filter: ACCEPT<br class=""> Output filter: REJECT<br class=""> IGP IPv4 table: master4<br class=""><b class=""> Channel ipv6<br class=""></b> State: UP<br class=""> Table: master6<br class=""> Preference: 100<br class=""> Input filter: <b class="">no_defaults</b><br class=""> Output filter: REJECT<br class=""> Routes: 0 imported, 0 exported<br class=""> Route change stats: received rejected filtered ignored accepted<br class=""> Import updates: 0 0 0 0 0<br class=""> Import withdraws: 0 0 --- 0 0<br class=""> Export updates: 49787 0 49787 --- 0<br class=""> Export withdraws: 261 --- --- --- 0<br class=""> BGP Next hop: 2001:XXXXXXXXXXX:2c9b<br class=""> IGP IPv6 table: master6<br class=""><b class=""> Channel ipv4<br class=""></b> State: DOWN<br class=""> Table: master4<br class=""> Preference: 100<br class=""> Input filter: no_defaults<br class=""> Output filter: REJECT<br class=""> IGP IPv4 table: master4<br class=""><br class="">This appears to be the result of <br class=""><br class=""><span style="font-size: 12px;" class="">template bgp ALL_BGP {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> local as MY_AS;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> ipv6 {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> add paths on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> graceful restart on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> import keep filtered on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> };</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> ipv4 {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> add paths on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> graceful restart on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> import keep filtered on;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> };</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class="">}</span><br style="font-size: 12px;" class=""><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class="">template bgp UPLINK from ALL_BGP {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> allow local as 4;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> ipv6 {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> export none;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> import filter no_defaults;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> };</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> ipv4 {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> export none;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> import filter no_defaults;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> };</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class="">}</span><br style="font-size: 12px;" class=""><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class="">protocol bgp BOGONS6 from UPLINK {</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> neighbor 2620:0:6B0::26E5:4207 as 65332;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> source address 2001:XXXXXXXXXX:fe00:2c9b;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class=""> multihop 255;</span><br style="font-size: 12px;" class=""><span style="font-size: 12px;" class="">}</span><br style="font-size: 12px;" class=""><br class="">(which is, as explained above, a result of simply <i class="">merging</i> former bird6.conf and bird.conf files)<br class=""><br class="">Again, this is somehow „explicable“, yet completely surprising and „Something must be done against that!!!!11!!11 BURN THE WITCH!!!“ ;-), either within the documentation or within the code.<br class="">(it seems the ipv6/ipv4 channel definitions within the templates each create their own instances instead of inheriting/enhancing (from) the ones upstream???)<br class=""><br class="">@Ondrej, et.al., is this even a „supported mode of operation“ → multiple IPv6 and IPv4 channels within one protocol?<br class=""><br class=""></li></ol><div class="">So this still <i class="">somehow</i> works, yet still with the 100% CPU consumption.</div><div class=""><br class=""></div><div class="">@bird-devs: How would you like to address above issues? Yes, I can probably clean up the config file, which would probably even make the 100%-issue go away. But imho it shouldn’t be possible in the first place to create configs like these without BIRD at least kicking and screaming loudly about it.<br class=""><br class="">NB: This a a test-setup on a test-machine, so I’ll happily create accounts for you, if you send me an ssh-pubkey through email, if you like to have a „live look“ at the beast!? (it practically lives in your garden anyway → 14ms RTT to nic.cz :-)</div></div><div class=""><br class=""></div><div class="">Liebe Grüße aus Berlin,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Clemens</div><div class=""><br class=""></div></body></html>