Patch to fix BGP ghost routes resulting from loops
I've created attached patches to prevent BGP route loops from turning into ghosts (issue reported earlier to the mailing list: http://marc.info/?l=bird-users&m=129433651229774&w=2). Instead of completely ignoring received BGP routes containing the router's own AS number, it should now handle them as if the prefixes are unreachable. We have tested the patch against git and it fixed the issue there. I've also made an (untested) patch against bird 1.2.5. -- Ivo
On Thu, Mar 10, 2011 at 01:54:33PM +0100, Ivo Smits wrote:
I've created attached patches to prevent BGP route loops from turning into ghosts (issue reported earlier to the mailing list: http://marc.info/?l=bird-users&m=129433651229774&w=2).
Instead of completely ignoring received BGP routes containing the router's own AS number, it should now handle them as if the prefixes are unreachable.
We have tested the patch against git and it fixed the issue there. I've also made an (untested) patch against bird 1.2.5.
Thanks for the patch. I already have semifinished patch that did some bigger changes to BGP error handling code and also fixes this problem, so i would not merge that, but it might be useful for others. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sun, Mar 20, 2011 at 04:31:34PM +0100, Ondrej Zajicek wrote:
On Thu, Mar 10, 2011 at 01:54:33PM +0100, Ivo Smits wrote:
I've created attached patches to prevent BGP route loops from turning into ghosts (issue reported earlier to the mailing list: http://marc.info/?l=bird-users&m=129433651229774&w=2).
Instead of completely ignoring received BGP routes containing the router's own AS number, it should now handle them as if the prefixes are unreachable.
We have tested the patch against git and it fixed the issue there. I've also made an (untested) patch against bird 1.2.5.
Thanks for the patch. I already have semifinished patch that did some bigger changes to BGP error handling code and also fixes this problem, so i would not merge that, but it might be useful for others.
Does 1.3.0 include your patch? -- Wanna turn ICANN into ICANN't? Join a darknet today: http://www.anonet2.org/darknet_comparison
On Fri, Apr 01, 2011 at 03:14:35PM +0000, Nick wrote:
Thanks for the patch. I already have semifinished patch that did some bigger changes to BGP error handling code and also fixes this problem, so i would not merge that, but it might be useful for others.
Does 1.3.0 include your patch?
Yes -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
W dniu 2011-04-01 17:14, Nick pisze:
Instead of completely ignoring received BGP routes containing the router's own AS number, it should now handle them as if the prefixes are unreachable.
We have tested the patch against git and it fixed the issue there. I've also made an (untested) patch against bird 1.2.5.
Thanks for the patch. I already have semifinished patch that did some bigger changes to BGP error handling code and also fixes this problem, so i would not merge that, but it might be useful for others.
Does 1.3.0 include your patch?
Oh, thanks for refreshing this thread, it gives some light on my mysterious problem I encountered yesterday while trying to upgrade from 1.2.5>1.3.0 on one of my route reflector client. I just switched binaries and left the same config, and when I started new bird, all my iBGP routes became unreachable. I didn't had time to debug it so I quickly turned back to 1.2.5 and left the problem for next week. Did I miss something? Shall I change something in configuration to have route reflector client working properly? Regards -- Adrian
On Sat, Apr 02, 2011 at 07:53:35AM +0200, Adrian Czapek wrote:
Oh, thanks for refreshing this thread, it gives some light on my mysterious problem I encountered yesterday while trying to upgrade from 1.2.5>1.3.0 on one of my route reflector client. I just switched binaries and left the same config, and when I started new bird, all my iBGP routes became unreachable. I didn't had time to debug it so I quickly turned back to 1.2.5 and left the problem for next week.
Did I miss something? Shall I change something in configuration to have route reflector client working properly?
So i understand that routes appear in the routing table but with unreachable destination? This is related not to mentioned patch, but to main changes in iBGP that triggered this major release, and it is probably unrelated to route reflector setting. Essentially, the next hop from NEXT_HOP attribute have to be resolvable through the routing table. See option 'gateway direct|recursive' in the documentation. Essentially, you have have three possibilities: - Just switch to the old behavior using 'gateway direct'. - If you have flat topology (one L2 network with attached border BGP routers) and do not use OSPF, you may add device routes using direct protocol, in that case you also have to add 'next hop self' to iBGP protocol on BGP border routers (not to the route server), because without that NEXT_HOP contains IP address of the border router of neighbor AS, which is usually one hop away. - If you use OSPF for the internal network, it should work just fine, but note that you should have in IGP table not only internal networks, but also the border networks connecting local and neighbor's border routers. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sat, Apr 02, 2011 at 12:16:38PM +0200, Ondrej Zajicek wrote:
So i understand that routes appear in the routing table but with unreachable destination? This is related not to mentioned patch, but to main changes in iBGP that triggered this major release, and it is probably unrelated to route reflector setting. Essentially, the next hop from NEXT_HOP attribute have to be resolvable through the routing table. See option 'gateway direct|recursive' in the documentation.
I can't find that in the documentation, but it doesn't matter, because my iBGP peerings fail when I upgrade a node to 1.3.0 (from 1.2.1). It sends a 0 router ID, even when the first line in my config sets a router ID. Is this also related to the main changes in iBGP, or is this something else? -- Wanna turn ICANN into ICANN't? Join a darknet today: http://www.anonet2.org/darknet_comparison
On Sun, Apr 03, 2011 at 03:30:56PM +0000, Nick wrote:
On Sat, Apr 02, 2011 at 12:16:38PM +0200, Ondrej Zajicek wrote:
So i understand that routes appear in the routing table but with unreachable destination? This is related not to mentioned patch, but to main changes in iBGP that triggered this major release, and it is probably unrelated to route reflector setting. Essentially, the next hop from NEXT_HOP attribute have to be resolvable through the routing table. See option 'gateway direct|recursive' in the documentation.
I can't find that in the documentation, but it doesn't matter, because my iBGP peerings fail when I upgrade a node to 1.3.0 (from 1.2.1). It sends a 0 router ID, even when the first line in my config sets a router ID. Is this also related to the main changes in iBGP, or is this something else?
No, this is bug: http://marc.info/?l=bird-users&m=130165846402471&w=2 Just explicitly configure router ID to fix that, or use bugfix from git version. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sun, Apr 03, 2011 at 06:32:26PM +0200, Ondrej Zajicek wrote:
On Sun, Apr 03, 2011 at 03:30:56PM +0000, Nick wrote:
On Sat, Apr 02, 2011 at 12:16:38PM +0200, Ondrej Zajicek wrote:
So i understand that routes appear in the routing table but with unreachable destination? This is related not to mentioned patch, but to main changes in iBGP that triggered this major release, and it is probably unrelated to route reflector setting. Essentially, the next hop from NEXT_HOP attribute have to be resolvable through the routing table. See option 'gateway direct|recursive' in the documentation.
I can't find that in the documentation, but it doesn't matter, because my iBGP peerings fail when I upgrade a node to 1.3.0 (from 1.2.1). It sends a 0 router ID, even when the first line in my config sets a router ID. Is this also related to the main changes in iBGP, or is this something else?
No, this is bug: http://marc.info/?l=bird-users&m=130165846402471&w=2
Just explicitly configure router ID to fix that, or use bugfix from git version.
This is interesting. I read that bug report and set a router ID in the first line in my config before my post. I also did birdc configure after setting a router ID in the config and it did not correct the problem. I left the router ID in the config when I switched back to 1.2.1 and now when I upgraded to 1.3.0 again it sends the router ID. Does birdc configure fail to update the router ID? -- Wanna turn ICANN into ICANN't? Join a darknet today: http://www.anonet2.org/darknet_comparison
On Sun, Apr 03, 2011 at 05:36:27PM +0000, Nick wrote:
This is interesting. I read that bug report and set a router ID in the first line in my config before my post. I also did birdc configure after setting a router ID in the config and it did not correct the problem. I left the router ID in the config when I switched back to 1.2.1 and now when I upgraded to 1.3.0 again it sends the router ID. Does birdc configure fail to update the router ID?
Generally, you can update router ID using configure (although it always restarts all protocols in that case), but in this case it didn't worked, because bird already used that router ID, just one internal variable in BGP had bad value. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Adrian Czapek -
Ivo Smits -
Nick -
Ondrej Zajicek