BGP next-hop-self

[_rucisco_]

Hi guys,

I have a simple BGP network with 3 ASs. 

I have configured eBGP sessions between R1 & R2, and R3 & R5. I have also configured iBGP sessions between loopback interfaces of R2 & R4, R4 & R3, and R2 & R3.

The next-hop-self parameter has been added in R2 and R3 because AS 2 is running RIPv2 to share just the loopback addresses and internal networks (R2-R4 and R3-R4, not the ones connected with AS 1 and AS 3).

R4's BGP table is as follows:

BGP table version is 4, local router ID is 4.4.4.4, vrf id 0
Default local pref 100, local AS 200
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i10.0.0.0/16      2.2.2.2                  0    100      0 100 i
*>i30.0.0.0/16      3.3.3.3                  0    100      0 300 i

Displayed  2 routes and 2 total paths

Next I show R4's routing table:

Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

R>* 2.2.2.2/32 [120/2] via 20.1.0.1, eth0, 02:05:52
R>* 3.3.3.3/32 [120/2] via 20.2.0.2, eth1, 02:01:45
C>* 4.4.4.4/32 is directly connected, lo, 02:00:54
B>  10.0.0.0/16 [200/0] via 2.2.2.2 (recursive), 01:05:07
  *                       via 20.1.0.1, eth0, 01:05:07
C>* 20.1.0.0/16 is directly connected, eth0, 02:13:26
C>* 20.2.0.0/16 is directly connected, eth1, 02:13:08
B>  30.0.0.0/16 [200/0] via 3.3.3.3 (recursive), 01:18:14
  *                       via 20.2.0.2, eth1, 01:18:14

I can see 10.0.0.0/16 (AS1's advertised prefix) and 30.0.0.0/16 (AS3's advertised prefix) both in the BGP table and routing table (via R2 and R3 respectively). However, when I ping from R1 to R5 and viceversa, these packets  do not traverse R4.

Can anyone explain why?

Thanks!

---

Edit: to solve a typo

[Georg Pauwen]

Hello,

--> I have configured eBGP sessions between R1 & R2, and R3 & R4.

Is this a typo ? I guess you mean between  R3 and R5 ?

Either way, post the full running configs of all 5 routers.

[_rucisco_]

You're right. It was a typo. I edited the question for future reference. I will include all 5 configurations next

[_rucisco_]

Here you have the running configs of all 5 routers:

R1

interface eth0
 ip address 20.0.0.1/16
!
interface eth1
 ip address 10.0.0.1/16
!
router bgp 100
 neighbor 20.0.0.2 remote-as 200
 !
 address-family ipv4 unicast
  network 10.0.0.0/16
 exit-address-family
!

R2

interface eth0
 ip address 20.0.0.2/16
!
interface eth1
 ip address 20.1.0.1/16
!
interface lo
 ip address 2.2.2.2/32
!
router rip
 network 20.3.0.0/16
 network 20.1.0.0/16
 network 2.2.2.2/32
!
router bgp 200
 neighbor 3.3.3.3 remote-as 200
 neighbor 3.3.3.3 update-source lo
 neighbor 4.4.4.4 remote-as 200
 neighbor 4.4.4.4 update-source lo
 neighbor 20.0.0.1 remote-as 100
 !
 address-family ipv4 unicast
  neighbor 3.3.3.3 next-hop-self
  neighbor 4.4.4.4 next-hop-self
 exit-address-family
!

R3

interface eth0
 ip address 20.3.0.1/16
!
interface eth1
 ip address 20.2.0.2/16
!
interface lo
 ip address 3.3.3.3/32
!
router rip
 network 3.3.3.3/32
 network 20.2.0.0/16
!
router bgp 200
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 update-source lo
 neighbor 4.4.4.4 remote-as 200
 neighbor 4.4.4.4 update-source lo
 neighbor 20.3.0.2 remote-as 300
 !
 address-family ipv4 unicast
  neighbor 2.2.2.2 next-hop-self
  neighbor 4.4.4.4 next-hop-self
 exit-address-family
!

R4

interface eth0
 ip address 20.1.0.2/16
!
interface eth1
 ip address 20.2.0.1/16
!
interface lo
 ip address 4.4.4.4/32
!
router rip
 network 20.2.0.0/16
 network 20.1.0.0/16
 network 4.4.4.4/32
!
router bgp 200
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 update-source lo
 neighbor 3.3.3.3 remote-as 200
 neighbor 3.3.3.3 update-source lo

R5

interface eth0
 ip address 20.3.0.2/16
!
interface eth1
 ip address 30.0.0.1/16
!
router bgp 300
 neighbor 20.3.0.1 remote-as 200
 !
 address-family ipv4 unicast
  network 30.0.0.0/16
 exit-address-family
! 

[Harold Ritter]

Hi @_rucisco_ ,

R4 is not being selected as the best path from either R2 and R3, hence it is not being used for transit traffic.

Regards,

[_rucisco_]

Not sure why you say R4 is not selected as the best path. Where do you see that? I get traffic reach R4 from either side.

[Harold Ritter]

Hi @_rucisco_ ,

That is what it should be if you use default configuration. The IGP cost will be higher going through R4 and this path will not be selected. You can "show bgp ipv4 uni 30.0.0.0 255.255.0.0" on R2 and "show bgp ipv4 uni 10.0.0.0 255.255.0.0" on R3 to verify that the path through R4 is not selected as the best path.

Regards,

[_rucisco_]

Hi @Harold Ritter 

This is what I get from R2

BGP routing table entry for 30.0.0.0/16
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  20.0.0.1
  300
    3.3.3.3 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best (First path received)
      Last update: Tue Dec  7 00:31:47 2021

R3:

BGP routing table entry for 10.0.0.0/16
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  20.3.0.2
  100
    2.2.2.2 (metric 3) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best (First path received)
      Last update: Tue Dec  7 00:44:55 2021

I don't see from these outputs that the path through R4 is not selected. Can you explain where should I look at? And how to solve the problem?

Thanks!

[Harold Ritter]

Hi @_rucisco_ ,

The path from R4 is not learnt, as R4 is not configured as a route reflector (RR). Even if R4 was configured as a RR, the next-hop would not be changed and the direct between path between R2 and R3 would still be selected. That is the real reason why you will never use the  path through R4 when you go from R1 to R5. 

Regards,

[_rucisco_]

Hi @Harold Ritter,

Just to really understand what is going on behind the scenes.

When I ping R5 from R1, the packet gets to R4 but doesn't go through. If I sniff traffic between R3 and R4, I see the ICMP echo requests from R5:

But I don't understand why doesn't it forward them??? They are being received by R4 (Frame's destination MAC is R4's) and 10.0.0.0/16 is in its routing table... 

And again, how should I solve this?

Thanks

[Harold Ritter]

Hi @_rucisco_ ,

The reason the ping fails is that it uses the outbound interface address (20.3.0.2) as a source address and the route to this address is not known on R1. Make sure you specify the eth1 interface IP address as the ping source address.

Regards,

[_rucisco_]

Hi @Harold Ritter 

Not sure I understood your point.

The problem I am facing now is not on the return path. The problem is that ICMP echo request packets sent by R5 (20.3.0.2) are not even going through R4 (and clearly don't reach R1).

Any ideas?

[Harold Ritter]

Hi @_rucisco_ ,

The ping packets are from R5 to R1 and you mentioned that the packets make it to R4. From the information you provided, R4 has a route for 10.0.0.0/16 towards R2.

B>  10.0.0.0/16 [200/0] via 2.2.2.2 (recursive), 01:05:07
  *                       via 20.1.0.1, eth0, 01:05:07

Can you provide a "show ip cef 10.0.0.0.1" from R4.

BTW, you should definitely do another test changing the source address. Otherwise the return packet will never make it back to R5.

Regards,

[_rucisco_]

Hi @Harold Ritter 

That's why I was a so puzzled, packets reach R4 and the destination is on the routing table...

After I advertised 20.0/16, 20.1/16, 20.2/16 and 20.3/16 from R2 and R3, it works but I don't understand why packets were not going through R4 before that...

The routing table of R4 now is

R>* 2.2.2.2/32 [120/2] via 20.1.0.1, eth0, 05:10:47
R>* 3.3.3.3/32 [120/2] via 20.2.0.2, eth1, 05:06:40
C>* 4.4.4.4/32 is directly connected, lo, 05:05:49
B>  10.0.0.0/16 [200/0] via 2.2.2.2 (recursive), 04:10:02
  *                       via 20.1.0.1, eth0, 04:10:02
B>  20.0.0.0/8 [200/0] via 2.2.2.2 (recursive), 01:21:03
  *                      via 20.1.0.1, eth0, 01:21:03
C>* 20.1.0.0/16 is directly connected, eth0, 05:18:21
B   20.2.0.0/16 [200/0] via 3.3.3.3 (recursive), 01:21:36
                          via 20.2.0.2, eth1, 01:21:36
C>* 20.2.0.0/16 is directly connected, eth1, 05:18:03
B>  20.3.0.0/16 [200/0] via 3.3.3.3 (recursive), 01:21:32
  *                       via 20.2.0.2, eth1, 01:21:32
B>  30.0.0.0/16 [200/0] via 3.3.3.3 (recursive), 04:23:09
  *                       via 20.2.0.2, eth1, 04:23:09

But to me eyes there is no difference with respect to the endpoints R1 (10.0.0.1/16) and R5 (30.0.0.1/16).

Any ideas why?

[_rucisco_]

Hi @Harold Ritter 

BTW, I didn't want to add the network command to check the use of next-hop-self. Now, after I advertised these networks to AS 1 and AS 3 they are also received via iBGP so what's the need for next-hop-self ?

Thanks