Hello, On the dn42 network (http://www.dn42.net) we have been seeing quite a few BGP ghost routes lately. After some research, it turns out that bird may not correctly handle received AS-paths containing the own AS number. Bird ignores incoming BGP routes containing the local AS number - completely. This may result in an older, now invalid, route not getting removed. I've reproduced this behaviour by sending fake BGP packets from AS1113 to AS1111. AS1111 is running bird, AS1113 is running a custom 'BGP speaker' which will send fake route updates. See below. Now I don't know whether it is appropriate to send routes with AS paths containing your peer's AS number (is it?), but it seems to happen in reality and bird does not handle this correctly, resulting in routing loops. I'm running bird version 1.2.5, the debian package. Reproducing the problem: -- Initially there is no such route bird> show route all for 1.3.3.99 1.3.3.0/24 unreachable [static1 17:36] * (200) Type: static unicast univ -- After sending a route for 1.3.3.99/32 via ASes 1113, 9992, 9991, 9993: bird> show route all for 1.3.3.99 1.3.3.99/32 via 10.11.1.7 on tap.ufonet [btest1 17:45 from 10.11.5.36] * (100) [AS9993i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1113 9992 9991 9993 BGP.next_hop: 0.0.0.0 BGP.local_pref: 100 -- After sending a route for 1.3.3.99/32 via ASes 1113, 9991, 1111, 9993 bird> show route all for 1.3.3.99 1.3.3.99/32 via 10.11.1.7 on tap.ufonet [btest1 17:45 from 10.11.5.36] * (100) [AS9993i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1113 9992 9991 9993 BGP.next_hop: 0.0.0.0 BGP.local_pref: 100 -- The route has not changed, but it should at least have been removed -- After sending an update marking the route unfeasible: bird> show route all for 1.3.3.99 -- Perhaps also interestingly, only after the BGP connection has been closed, bird contains to the earlier state: bird> show route all for 1.3.3.99 1.3.3.0/24 unreachable [static1 17:36] * (200) Type: static unicast univ
$quoted_author = "Ivo Smits" ;
On the dn42 network (http://www.dn42.net) we have been seeing quite a few BGP ghost routes lately. After some research, it turns out that bird may not correctly handle received AS-paths containing the own AS number. Bird ignores incoming BGP routes containing the local AS number - completely. This may result in an older, now invalid, route not getting removed.
This sounds like it's working correctly. Bird is effectively ignoring the route with it's own AS in the path. The older route will therefore not be displaced. It would require a specific BGP withdrawal for the old route to go away in this context. cheers Marty
Op 6-1-2011 20:27, Martin Barry schreef:
$quoted_author = "Ivo Smits" ;
On the dn42 network (http://www.dn42.net) we have been seeing quite a few BGP ghost routes lately. After some research, it turns out that bird may not correctly handle received AS-paths containing the own AS number. Bird ignores incoming BGP routes containing the local AS number - completely. This may result in an older, now invalid, route not getting removed. This sounds like it's working correctly.
Bird is effectively ignoring the route with it's own AS in the path.
The older route will therefore not be displaced. That does not make much sense to me. The sender can have only one useable route to that destination, so once it sends an update for that destination, one can safely assume that the old route is no longer used. Not doing so will most likely result in routing tables losing synchronization, resulting in loops and ghost routes. It would require a specific BGP withdrawal for the old route to go away in this context. I've done another test and it turns out that bird does not send the withdrawal in this context.
Thanks for the quick reply. Cheers, Ivo
On Thu, Jan 06, 2011 at 09:23:06PM +0100, Ivo Smits wrote:
Op 6-1-2011 20:27, Martin Barry schreef:
$quoted_author = "Ivo Smits" ;
On the dn42 network (http://www.dn42.net) we have been seeing quite a few BGP ghost routes lately. After some research, it turns out that bird may not correctly handle received AS-paths containing the own AS number. Bird ignores incoming BGP routes containing the local AS number - completely. This may result in an older, now invalid, route not getting removed. This sounds like it's working correctly.
Bird is effectively ignoring the route with it's own AS in the path.
The older route will therefore not be displaced. That does not make much sense to me. The sender can have only one useable route to that destination, so once it sends an update for that destination, one can safely assume that the old route is no longer used. Not doing so will most likely result in routing tables losing synchronization, resulting in loops and ghost routes.
You are right. Surprisingly, it seems that RFC 4271 does not explictly specify how to handle such case. But generally, it is bad behavior to just ignore an update that is invalid for any reason - receiver should either interpret it as a withdraw or drop the session. I will check that and fix it. -- 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 (3)
-
Ivo Smits -
Martin Barry -
Ondrej Zajicek