BGP Next-hop-Self explained

How and when to use BGP next-hop-self

I have created a small ISP scenario with a Customer and an Upstream router to simulate yet another BGP command that is used often in BGP scenarios. As we all know BGP advertises destinations, but to use those destinations BGP protocol also is using a next-hop value inside a BGP update message.

For starters let us look at the diagram. 

I have preconfigured the BGP proccess with the coressponding Autonomous systems. In this scenario we are using simulated WAN links between the BGP speaking routers as the neighbor addresses. We are not using an eBGP multihop, or no distribution. This is how we will see the problem and the solution. Now let us take look at the configs.

ISP1

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.1 255.255.255.252  << Wan link to iBGP router

 duplex auto

 speed auto

!

interface FastEthernet2/0

 ip address 192.168.1.1 255.255.255.252  << link to Customer

 duplex auto

 speed auto

!

router ospf 1

 router-id 1.1.1.1

 log-adjacency-changes

 passive-interface FastEthernet2/0

 network 172.16.1.0 0.0.0.3 area 0

!

router bgp 500

 no synchronization

 bgp router-id 1.1.1.1

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255

 neighbor 172.16.1.2 remote-as 500

 neighbor 192.168.1.2 remote-as 1

 no auto-summary

ISP2

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.2 255.255.255.252   << link to iBGP neighbor

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.3.1 255.255.255.252 <<link to UPSTREAM

 duplex auto

 speed auto

!

router ospf 1

 router-id 2.2.2.2

 log-adjacency-changes

 passive-interface FastEthernet1/0

 network 172.16.1.0 0.0.0.3 area 0

!

router bgp 500

 no synchronization

 bgp router-id 2.2.2.2

 bgp log-neighbor-changes

 network 2.2.2.2 mask 255.255.255.255

 neighbor 172.16.1.1 remote-as 500

 neighbor 192.168.3.2 remote-as 100

 no auto-summary

We can now verify the bgp neighborships between the iBGP routers inside the ISP domain. Everything is ok and the prefixes are being received.

ISP1#sh ip bgp summary

BGP router identifier 1.1.1.1, local AS number 500

BGP table version is 14, main routing table version 14

5 network entries using 585 bytes of memory

5 path entries using 260 bytes of memory

5/4 BGP path/bestpath attribute entries using 620 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1513 total bytes of memory

BGP activity 8/3 prefixes, 9/4 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.16.1.2      4   500         56      57           14            0              0 00:24:42        2

The configs on the other two router are very similar. We are only advertising the loopbacks.

CUSTOMER

interface Loopback0

 ip address 10.10.10.10 255.255.255.255

!

interface Loopback1

 ip address 100.100.100.1 255.255.255.0

!

interface Loopback2

 ip address 50.50.50.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.1.2 255.255.255.252

 duplex auto

 speed auto

!

router bgp 1

 no synchronization

 bgp router-id 10.10.10.10

 bgp log-neighbor-changes

 network 50.50.50.0 mask 255.255.255.0

 network 100.100.100.0 mask 255.255.255.0

 neighbor 192.168.1.1 remote-as 500

 no auto-summary

UPSTREAM

interface Loopback0

 ip address 5.5.5.5 255.255.255.255

!

interface Loopback1

 ip address 200.200.200.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.3.2 255.255.255.252

 duplex auto

 speed auto

!

router bgp 100

 no synchronization

 bgp router-id 5.5.5.5

 bgp log-neighbor-changes

 network 200.200.200.0

 neighbor 192.168.3.1 remote-as 500

 no auto-summary

We should achieve full BGP meshed routing tables inside the ISP autonomous system. If we see that is not the case. Let us se what networks the Customer is advertising.

CUSTOMER#sh ip bgp neighbors 192.168.1.1 advertised-routes

BGP table version is 13, local router ID is 10.10.10.10

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 50.50.50.0/24    0.0.0.0                  0         32768 i

*> 100.100.100.0/24 0.0.0.0                  0         32768 i

Total number of prefixes 2

We see two prefixes from the customer. We shall now see the output from the BGP RIB table inside the second router of the ISP Autonomous system.

ISP2#sh ip bgp

BGP table version is 8, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       172.16.1.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

* i50.50.50.0/24    192.168.1.2              0    100      0 1 i

* i100.100.100.0/24 192.168.1.2              0    100      0 1 i

*> 200.200.200.0    192.168.3.2              0             0 100 i

Two prefixes learned from customers (50.50.50.0/24 and 100.100.100.0/24) are inside the BGP table, but there is no > sign. This means that they will not be inside the routing table and shall not be advertised to the eBGP neighbor Upstream. The mein problem is that the ISP2 router cannot reach the NEXT HOP address.

ISP2#sh ip route 192.168.1.2

% Network not in table

To remedy this problem we will use the next-hop-self command under the BGP proccess of the ISP1 routers. This command will tell the iBGP speaking router to change the BGP next-hop attribute to the known IP address to the router ISP2. This attribute is preserved in eBGP connections, thus the next-hop is not seen by the ISP2 router.

ISP1(config-router)#neighbor 172.16.1.2 next-hop-self

Now we can take look at the RIB table of the ISP2 router.

ISP2#sh ip bgp

BGP table version is 10, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       172.16.1.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*>i50.50.50.0/24    172.16.1.1               0    100      0 1 i

*>i100.100.100.0/24 172.16.1.1               0    100      0 1 i

*> 200.200.200.0    192.168.3.2              0             0 100 i

As the routing plane is in fuction the data plane is working fine. We can use a simple ping to verify that.

ISP2#ping 100.100.100.1 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:

Packet sent with a source address of 2.2.2.2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/48/64 ms

Thanks !!!