In the last article, we explored multihop EBGP, which allows BGP speakers to form an EBGP session without being directly connected. In this article, we will be looking at one of the path attributes used in BGP UPDATE messages – the NEXT_HOP attribute. Although we will see other attributes as we go on in this series, I want to focus on this NEXT_HOP attribute in this article because of the many values it can take depending on the scenario.

The NEXT_HOP attribute is a well-known mandatory attribute in BGP. Well-known means that all BGP implementations must recognize this attribute while mandatory means that it must be sent in all UPDATE messages that contain an NLRI.

CCNA Training – Resources (Intense)

Note: Refer to the first article in this BGP series for more information on the UPDATE message.

The NEXT_HOP attribute is used to specify the next hop address to be used for the destination prefix(es) listed in the NLRI portion of the UPDATE message. However, this attribute can vary depending on the type of BGP session that has been formed between the BGP peers and whether the destination network is within the AS or outside it. We will now consider these different case studies.

Case study #1: IBGP peers; Destination within the same AS

When the advertising BGP speaker is sending an UPDATE message to the receiving BGP peer, both peers being in the same AS (IBGP) and the destination(s) in the message are also within the same AS, then the NEXT_HOP is the IP address of the advertising router for that destination. For a directly connected network on the advertising BGP speaker, the NEXT_HOP is the IP address of the advertising BGP speaker with which it reaches the receiving BGP peer.

Note: “advertising router for that destination” may not be the same as the advertising BGP speaker; it could be a neighbor of the advertising BGP speaker.

We will look at two different scenarios to explain this. The first scenario is a destination (1.1.1.1/32) directly connected to one of the BGP peers (R1).

The BGP configuration on the routers is as follows:

hostname R1
!
router bgp 1
 neighbor 192.168.12.2 remote-as 1
 network 1.1.1.1 mask 255.255.255.255
hostname R2
!
router bgp 1
 neighbor 192.168.12.1 remote-as 1

When the BGP session is established, R1 sends an UPDATE message to R2 containing the 1.1.1.1/32 NLRI as shown below:

Notice the NEXT_HOP attribute value for that destination is 192.168.12.1, which is the IP address R1 uses to reach R2.

The second scenario we will consider under this section is where the destination network is not directly connected to the advertising BGP speaker as shown in the network diagram below:

R1 and R2 are the only BGP speakers in AS1; R2 and R3 run EIGRP and so, R2 redistributes EIGRP networks into BGP. The configuration changes on R2 are as follows:

router eigrp 10
 no auto
 network 192.168.23.0 0.0.0.255
!
router bgp 1
 redistribute eigrp 10

If you look at the snapshot of the UPDATE message sent by R2 to R1, you will notice that the next hop for destination 3.3.3.3/32 is 192.168.23.3 which is the IP address of R3. This is because R3 is the advertising router for that destination.

This second scenario tells us something: R1 must know how to reach the 192.168.23.3 next hop. If R1 cannot reach the next hop address, the route will not be installed in its IP routing table. In our case, since I am redistributing all EIGRP routes, we will be fine.

Case study #2: IBGP Peers; Destination outside the AS

When an advertising BGP peer is sending an update to an IBGP peer for a destination that is external to their AS, then the NEXT_HOP is the IP address of the external peer from which the destination was learned. Let’s use the network diagram below to illustrate this point:

I have an IBGP session between R1 and R2 and an EBGP session between R2 and R3. R3 will send an UPDATE message for the 3.3.3.3/32 NLRI to R2. R2 will in turn send an UPDATE message for that network to R1 without changing the NEXT_HOP attribute (i.e. retaining the IP address of R3, the external peer).

Case study #3: EBGP peers

For routing updates between EBGP peers, the default behavior for the NEXT_HOP is quite simple: it is the IP address of the advertising BGP speaker. We will use the network diagram below to illustrate this point:

R2 receives the 1.1.1.1/32 route from R1 with a next hop of 192.168.12.1 (refer to case study #1). However, when R2 shares this route with R3, it will change the next hop to the IP address that it used to establish a BGP session with R3 i.e. 192.168.23.2.

Case study #4: Multi-access network

When BGP peers are connected to a multi-access network such as Ethernet, and the advertising router for a particular destination is also on the same subnet, then the NEXT_HOP for that destination is the IP address of the advertising router.

Let’s use the network scenario below to explain this concept:

R2 is configured to redistribute EIGRP routes into BGP. Normally, since R2 and R3 are EBGP peers, when R2 sends the update for route 1.1.1.1/32, it should set the NEXT_HOP as its own IP address (i.e. 192.168.123.2). However, because the advertising router for 1.1.1.1/32 (which is R1) is on the same subnet as R3, R2 will set the NEXT_HOP as R1’s IP address i.e. 192.168.123.1.

Note: In this scenario, R2 and R3 are EBGP peers; however, the same thing will happen (implicitly) if they were IBGP peers. This is because for IBGP peers and destinations within the same AS, the NEXT_HOP is set to the IP address of the advertising router for that destination, which is R1 in this case. Refer to the second scenario under Case study #1.

Keep in mind that all the cases we have considered are the default behavior of BGP for the NEXT_HOP attribute. This default behavior can be overwritten, by using the next-hop-self command in Cisco, for example.

Summary

In this article, we have considered four case studies regarding the NEXT_HOP attribute used in BGP as follows: for IBGP peers and a destination within the AS, the next hop is set to the router that advertised that destination; for IBGP peers and a destination outside the AS, the next hop is the IP address of the external peer that advertised that destination; for EBGP peers, the next hop is the IP address of the advertising BGP peer; finally, on multi-access networks, the next hop is the IP address of the router that advertised the destination if that router is on the same subnet as the receiving BGP peer.

I hope you have found this article insightful and I look forward to the next article in the series.

References and further reading

  1. RFC 4271: A Border Gateway Protocol 4 (BGP-4): http://tools.ietf.org/html/rfc4271
  2. Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron.
  3. Routing TCP/IP, Volume II, by Jeff Doyle.