route withdraws on BGP route-refresh
Hello all, While debugging a route-refresh issue we discovered that when a route-refresh is received, bird, instead of just sending an update containing the exported routes, also withdraws **all known routes** from its peer. In our case, it withdraws the whole FIRT sending multiple BGP updates. Is this the expected behaviour? We are using bird 1.4.5. We believe that the opposite router has trouble processing all those withdrawed routes which leads to other connectivity issues.
On Thu, Dec 10, 2015 at 12:10:35PM +0200, Christos Trochalakis wrote:
Hello all,
While debugging a route-refresh issue we discovered that when a route-refresh is received, bird, instead of just sending an update containing the exported routes, also withdraws **all known routes** from its peer. In our case, it withdraws the whole FIRT sending multiple BGP updates. Is this the expected behaviour? We are using bird 1.4.5.
We believe that the opposite router has trouble processing all those withdrawed routes which leads to other connectivity issues.
Any comments on that? Let me restate the issue, bird withdraws every route in its routing table despite the fact that those routes were never exported to that protocol. I am not familiar with bird internals so I don't know if bird keeps track of the exported routes per protocol.
I dont know the bird internals exactly, but iirc this is implemented to save tracking as you mentioned in the code. According to RFC 2918 Otherwise, the BGP speaker shall re- advertise to that peer the Adj-RIB-Out of the <AFI, SAFI> carried in the message, based on its outbound route filtering policy. --> No withdraw mentioned I think in some situations it makes sense to withdraw all known routes, but the still active ones to create a consistent table on the receiver side. What is the peer device btw? Rgds, SJ P.S.: Sorry for TOFU Christos Trochalakis <yatiohi@ideopolis.gr> schrieb am Mo., 28. Dez. 2015 09:46:
On Thu, Dec 10, 2015 at 12:10:35PM +0200, Christos Trochalakis wrote:
Hello all,
While debugging a route-refresh issue we discovered that when a route-refresh is received, bird, instead of just sending an update containing the exported routes, also withdraws **all known routes** from its peer. In our case, it withdraws the whole FIRT sending multiple BGP updates. Is this the expected behaviour? We are using bird 1.4.5.
We believe that the opposite router has trouble processing all those withdrawed routes which leads to other connectivity issues.
Any comments on that?
Let me restate the issue, bird withdraws every route in its routing table despite the fact that those routes were never exported to that protocol. I am not familiar with bird internals so I don't know if bird keeps track of the exported routes per protocol.
On Mon, Dec 28, 2015 at 10:41:26AM +0200, Christos Trochalakis wrote:
On Thu, Dec 10, 2015 at 12:10:35PM +0200, Christos Trochalakis wrote:
Hello all,
While debugging a route-refresh issue we discovered that when a route-refresh is received, bird, instead of just sending an update containing the exported routes, also withdraws **all known routes** from its peer. In our case, it withdraws the whole FIRT sending multiple BGP updates. Is this the expected behaviour? We are using bird 1.4.5.
We believe that the opposite router has trouble processing all those withdrawed routes which leads to other connectivity issues.
Any comments on that?
Let me restate the issue, bird withdraws every route in its routing table despite the fact that those routes were never exported to that protocol. I am not familiar with bird internals so I don't know if bird keeps track of the exported routes per protocol.
Hi BIRD does not explicitly keep track of the exported routes per protocol. In normal operation, it just evaluates filters on both the old and the new route to see if it is necessary to send an update - if both are rejected, then no withdraw is sent. But this approach is not used for full table refeed (which may be triggered by reconfiguration, explicit command or received route-refresh). In refeed, every available route is either propagated or withdrawn, mainly to handle situation where export filters were changed and therefore we cannot reliably decide whether routes were exported in the past. -- 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)
-
Christos Trochalakis -
Ondrej Zajicek -
Stefan Jakob