Cisco SPCOR – The BGP NEXT_HOP Attribute

1 Comment
| | |

It is time for us to tackle the last of the well-known, mandatory BGP path attributes we must master. It is none other than the NEXT_HOP path attribute.

This certainly seems like a simple path attribute and it is perfectly understandable that this would be in the well-known and mandatory category. What is surprising to some about this attribute, however, is the fact that it functions differently from the IGPs that we might be more accustomed to working with. While it might seem off putting at first, you will quickly acclimate to the rules of the NEXT_HOP behavior in BGP. Here are these rules:

  1. For eBGP peers, the NEXT_HOP is the IP address of the advertising router’s interface. This acts just as we would expect coming from the world of IGPs.
  2. For iBGP peers, the NEXT_HOP is the IP address of the advertising router’s interface, but only if the destination is in the local AS. Again, this behavior would be consistent with what we expect to see in our IGPs, and you will notice this behavior when your iBGP speaker is actually originating the prefix in the local AS, therefore setting its own NEXT_HOP for the prefix.
  3. For iBGP peers, the NEXT_HOP is the IP address of the external peer from which the prefix was learned. This is DEFINITELY different from what we are accustomed to with our IGPs.

Rule #3 really shows how BGP is more of an AS to AS routing protocol, as opposed to a router to router protocol as we are accustomed to in the world of IGPs. This can often cause reachability issues of course. We must remember that the NEXT_HOP attribute may be populated with a value outside of our AS and one that might present reachability issues.

Remember, also, from your study of the BGP best path selection algorithm, you realize that BGP quickly ignores a prefix for best path selection should the NEXT_HOP value of that prefix be unreachable. This is often why we do not see the prefixes we might expect in our practice labbing with the protocol.

What are common solutions to potential reachability issues with NEXT_HOP in BGP? Well, there are plenty and they include:

  • Ensuring the remote subnet is reachable using static routing
  • Using an IGP configured passively on the external facing interface (to advertise the subnet into the IGP)
  • Use the next-hop-self command in BGP to change the behavior of Rule #3

When you are in your multiple-choice based SPCOR exam, this is all very simple. Where things can get, well, interesting, is when we are in a CCIE lab exam environment. Here, you will have to read very closely to see what method you may use to “fix” any issues with NEXT_HOP. Remember, make no assumptions and be sure to see what solution(s) are acceptable given the opening rules of the exam, and the precise wording of the tasks in the IGP and EGP sections.

One Comment

  1. Hello, good article.
    In the case of an SP Unified-MPLS network with BGP Label-Unicast allocating labels between IGP domain (RFC 3107), we can also use AIGP BGP path attribute to account the end-to-end IGP metric path. In term of BGP best path selection process, Lowest AIGP cost comes now in 3rd position, just after Local-Preference and before AS-PATH. If AIGP is not used, main trigger of the BGP best path selection would be for BGP to choose the “Lowest IGP metric to the BGP next-hop”.

Comments are closed.