BGP import_table & graceful restart issue

Ondrej Zajicek santiago at crfreenet.org
Mon Mar 25 22:27:18 CET 2019


On Mon, Mar 25, 2019 at 06:35:43AM +0000, Arvin Gan wrote:
> Hi Ondrej,
>     Thanks for your answer :).
>     I checked the RFC 4271 and RFC 4274, maybe what you said it's correct behavior based on RFC4271, " The phrase "the BGP connection is closed" means the TCP connection has been closed, the associated Adj-RIB-In has been cleared, and all resources for that BGP connection have been deallocated. Entries in the Loc-RIB associated with the remote peer are marked as invalid.The local system recalculates its best routes for the destinations of the routes marked as invalid. Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system." 
>     And RFC4274 said, "when the Receiving Speaker detects termination of the TCP session for a BGP session with a peer that has advertised the Graceful Restart Capability, it MUST retain the routes received from the peer for all the address families that were previously received in the Graceful Restart Capability and MUST mark them as stale routing information."
>   
>     RFC4274 said  that retain the routes received from the peer ......, my understand is peer should retain routes in Adj-RIB-IN table and mark them as stale. Normally, the BGP route in local-RIB or adj-RIB-out should come from Adj-RIB-IN table.  The behavior of BIRD for GR, BGP route is  NOT  in adj-RIB-in, but in local-RIB or adj-RIB-out, I think it's not a complete behavior. What's your opinion ?

My opinion is that for proper graceful restart behavior, keeping FIB and
Loc-RIB is important. State of Adj-RIB-In is more or less irrelevant.
That is why it is not discussed in RFC 4724.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."


More information about the Bird-users mailing list