BGP next-hop self

If you read my earlier post,  about the  bgp path-attributes  MEDs & NEXT_HOP, and remember that 3 router topology? Will I re-used that  topology for this blog and for further training.

The iBGP peers expects other iBGP peers to known the next-hop address,  or have reachability to the next-hop. These bgp iBGP peers do NOT modify the BGP next-hop information. So let's do some changes to my original design, and hopefully you will learn 2 unique behavior with BGP.

Here's the new topology;

R1 = AS1

R2 = AS2

R3 = AS2

Okay R1 config stays the same for this demo & training session ;

R1:

But on R2,  we made some changes,  1> we remove the neighbor 2.2.2.2 remote-as 3 and  2> converted her to AS#2;

And R3 is also now in  AS#2

Okay good so far ?

Well let's see, 1st let's look at the  R2  bgp table to ensure we still see 10.10.10.0/24 from  R1 ( AS#1 ).

Okay nothing changed. It looks good. Well let's see what  R3  who's now in AS#2 and what does he see.

Okay you should  see 2 things & I highlighted one of them.

1st the bigger issue;  <1.1.1.1>  is inaccessible due to the next_hop path_attribute was not changed by 2.2.2.1 ( R2 with in AS#2 )

2nd, we find the mertric value offered via R1 ( 1.1.1.1 ) is now  included for 10.10.10.0/24 on R3. Yes the metric stayed within the AS#2. So any iBGP peers would learn the same metric as the direct attached  R2 router.

Okay so how do we get past this inaccessible issue? 

Easy I will show you the rookie method,  if they would even noticed it. They typically would install a  static route point to  R2 on R3 route table.

Okay that fixed the problem or at least removed the inaccessible warning. But that's not the right recommended way or means or is it? We could also redistribute the  1.1.1.0/32 network from r2 perspective into AS2. And most service-provider does that in some cases.

But, you have one more  option; the execution of  next-hop-self  on the iBGP peer that learns the eBGP paths.

Okay we are going to do  the following & demonstrate this behavior;

1: first we  remove the static route that a rookie would install on R3

2:  and on R2 we will set the iBGP neighbor with the next-hop-self

3: we will clear the  iBGP relationship and re-monitor the bgp table on R3

on R2

and  on  R3

Notice the next-hop information is now  populated with 2.2.2.1 address ( R2 )  vrs the original  1.1.1.1 address ( R1 ). Cool, we have reachability  via iBGP to this route advertised via R1. And R3 has no knowledge in this case of the R1 bgp speaker. It's only BGP relationship is known and established with R2 via it's iBGP session.

Key take aways;

• metrics stay within the AS that learns it, but is not delivered outside of that AS

• be cautious of how BGP next-hop reachability  works &  with your iBGP peers

• iBGP peer that learns a eBGP path  do NOT by default ,  re-adjust the path_attribute  NEXT_HOP

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a----t----socpuppets ---d---o---t---com

   ^      ^

=( *    * )=

        @

      /     \