09-05-2019 07:16 AM
Would like to know if inactive prefixes in Internet cloud take more time for network convergence
Multihome network topology
two internet routers(A & B) -each with one internet link
different ISP for each router
A & B have interconnection ( iBGP)
X.X.X.X/23 has been divided into two /24 ranges
1 st x.x.x.x/24 and x.x.x.x/23 are advertised from A router to internet
2 nd X.X.X.X/24 and X.X.X.X/23 are advertised from B router to Internet
A router advertised its /24 range to B router and vice versa
so, longest prefix is preferred as long as both ISPs are available
At times, when there is link failure at one of the routers, ( ex A), previously advertised /24 from A to internet was not reachable. Ideally it should be reachable through B router wit /23 range and traverse over CE-CE and to FWs at downstream
Could anyone confirm if inactive prefixes ( our case /23) will take more time as there are mostly not used . technically, it should not be. It should follow the BGP updates and prefixes withdrawn messages
09-07-2019 04:41 AM
Hello NDP,
>>
At times, when there is link failure at one of the routers, ( ex A), previously advertised /24 from A to internet was not reachable. Ideally it should be reachable through B router wit /23 range and traverse over CE-CE and to FWs at downstream
Could anyone confirm if inactive prefixes ( our case /23) will take more time as there are mostly not used . technically, it should not be. It should follow the BGP updates and prefixes withdrawn messages.
BGP propgates BGP updates that can have a withdraw section.
But, depending on the type of fault and depending on how RA generates its own /23 prefix RA may or may not withdraw both x.x.x.x/24 and x.x.x.x/23.
If you use a static route to null0 + network x.x.x.x/23 this is not withdrawn when link to /24 prefix fails
If you use the aggregate-address to generate the x.x.x.x/23 be aware that the iBGP session provides you a valid component route
>> A & B have interconnection ( iBGP)
So before making suppositions about BGP propagation of inactive routes you should ask yourself the following question:
During the fault, RA has withdrawed x.x.x.x/24 AND x.x.x.x/23 or only x.x.x.x/24 ?
Depending on what you find you can get an explanation for the seen issues.
Note:
You have not provided any details on what the fault was and how RA and RB are interconnected, if there is an internal link where the iBGP session can be established (I have supposed so for your expectations).
The iBGP session provides an alternate component route to make the aggregate considered still valid even if the direct link to the local /24 IP subnet is lost. If so RA withdraws the x.x.x.x/24 but does not withdraw the x.x.x.x/23. And this causes issues as from the internet packets with destination in the x.x.x.x/24 can still be sent to RA.
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide