cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
747
Views
0
Helpful
1
Replies

Route Convergence in Internet cloud_Query

NDP
Level 1
Level 1

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

 

1 Reply 1

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

 

Review Cisco Networking for a $25 gift card