We'll now look at the next BGP attribute, the Next Hop. And as the name suggests, that's literally the next router along the path. And it's actually the router where you've heard the BGP announcement from. So we've just seen the AS Path, and the next hop is the IP address of the next router, so the router in the adjacent AS you've heard the prefix from. So if we refer to the diagram router B will hear the prefix coming from router A and it hears the prefix coming from So it will set the next hop address to be, Now this is for eBGP, the address of the next hop is the address of the external neighbor. iBGP is different. iBGP, according to the standard, the next hop is learned from eBGP, so nothing changes. So when router B sends the prefix onward to router C, the next hop address is still, per specification. So this is actually quite interesting as we'll see next. Now before we move on, next hop is the mandatory attribute. You have to have an IP address of the next router. If you don't have an IP address you can't get to that destination. But the attribute is non-transitive, it's not passed from autonomous system to autonomous system. The next hop is set as the prefix enters the Autonomous System. So if we look at iBGP first. Now, if we introduce a prefix say we again, we look at this diagram, we move to router B, we introduce say into our iBGP. If we go to another router in the Autonomous System, say router D we see that that prefix, has the next hop address of that is the loopback address of router B. Remember we set up iBGP between the loopback interfaces. We could set up iBGP on point-to-point links as we already covered, but best practice is between the loopbacks, which means we're not dependent on any of the physical infrastructure on the network. So in the diagram there, the lines between the routers, they might be iBGP sessions there might be the physical links, I haven't specified and it doesn't matter. But they definitely are the iBGP sessions because iBGP is fully meshed. Because we don't have this dependency in the physical infrastructure, how we get to the loopback of router B is left entirely to the IGP. So whether we're using OSPF for IS-IS, we use the IGP to find out how to get to that loopback and this is what we call recursive route lookup. Router D will look in the IGP to find out how to get to loopback of router B. And so if any of the physical links break, OSPF or IS-IS takes care of rerouting to bypass the broken links. BGP doesn't need to care about it. And this is why we really like this, it makes iBGP topology independent; independent of what the internal network infrastructure looks like. The other piece I want to look at is the third party next hop. This is kind of interesting too, and it's actually made use of in an Internet Exchange Point (IXP). And we'll look at Internet Exchange Points at some juncture later on. For example we've got AS 200, AS 201, AS 202. AS 200, 201, and 202 are all sitting on the same shared media, say Ethernet for sake of argument. Router C in AS 200, is peering eBGP with router B in AS 201. Router B sees the prefix coming from router C, and sets the next hop to be which is router C's IP address on that shared media. Router B then sends the prefix through its eBGP session with AS 202. Router A rather than setting the next hop to be sees that the prefix arriving already has a next hop address of our device on that shared media, so it leaves that existing . It does not change the address to This is the third party next hop. It means that traffic from AS 202 to AS 200 will go directly from router A to router C. It will not jump through router B. This is hugely advantageous at an Internet Exchange Point which has implemented something called a route server. The route server would be in AS 201. The route server would listen to the prefixes coming from all the Autonomous Systems on the network, and then pass those prefixes on to the other Autonomous Systems on the the same physical network according to whatever policy has been set. Very very efficient and there's no extra configuration needed. This is all taken care of within the BGP specification. So let's look at the next hop best practice. Now Cisco IOS default is the BGP standard. And that is for the external next hop to be propagated unchanged to iBGP peers. It means that IGP has to carry the external next hops. Now we've been talking about scaling the IGP earlier on in this series. And if we've got to carry all the external next hops for any sizable network that's a unnecessary burden on the IGP. IGP design it's all about speed of convergence, keeping the number prefixes to the absolute minimum. And so if we've got to add all these external next hops into IGP, this is going to cause a serious scaling issue. If we forget to carry the external next hop it means that external network becomes invisible. You can't get to a BGP destination if the next hop is not reachable, and this is an often caused issue in many many network operations, network infrastructure, where the operators have been puzzling over, Why can I not get to this neighbor? Why can I not get to this destination? More often than not, even when the destination is in the BGP table the next hop is not reachable. So actually industry best practice is to change the external next hop from what the BGP standard says and make it that of the local router, so where the prefix came from outside the Autonomous System, make it that of the local router, the local border router. The Cisco IOS command to do it is just `neighbor next-hop-self`. Other BGP implementations will have a similar construct as well. And as I said this is very much industry best practice now, and encourage all implementations of BGP, all deployments of BGP, to do this, as it saves unnecessary extra load on the IGP. So summarizing all this, IGP should carry route to the next hops. We're going to make use of the recursive route lookup, which means we have unlinked BGP from the actual physical topology. We use next hop self for external next hops. And all this allows the IGP to make the intelligent forwarding decision.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.