A.3.a) “Next-hop” role within an Ebgp or Ibgp session
- We know commonly that BGP uses its path selection on mandatory well-known BGP attributes: the “Origin,” the “as-path“, and the routing feature “next-hop“.
Origin attribute is easy to understand, as-path is based on the fact that the boundary router modifies the as-path element, every time information about a particular prefix passes over an AS-border.
When a router is the primary one to originate a route in BGP, the as-path attribute is empty. And it is well-known that each time that the route crosses an AS-border, the diffusing AS-network prepends its own as-number to appear first in the as-path. As a result, we can pathway the sequence of autonomous systems through the route which has passed by using this aspect.
Now it could be interesting to focus the importance of the next-hop attribute in a BGP context. This notion need to be understood deeply, because path selection and debugging mechanisms are often related to this feature.
- We can think of the next-hop as the outgoing IP-address of the router (the address that is used to establish the BGP TCP session) connected by a BGP session. When a router receives a BGP update:
- it analyzes the joined attributes and checks them with the attributes that were attached to the same IP subnet when it was received from a different source.
- Regarding the next-hop attribute, the router also modifies it when the route passes through the network.
- This attribute indicates the IP address of the next-hop router, which is, in fact, the router to which the receiving router should forward the IP-packets toward, in order to reach the destination that is advertised in the routing update.
- To summarize, the next-hop designates the next-hop IP-address used for packet forwarding and is usually set to the IP-address of the sending Ebgp speaker.
- For your information, it is rare, but we can set the next-hop to a third-party IP-address, this in order to optimize the traffic engineering. This can happen when we wish the egress traffic to leave through a specific interface, by implementing a policy base routing process (command “set next-hop”).
- The next-hop attribute is not changed on Ibgp updates, meaning that when the border router forwards the BGP updates on Ibgp sessions; the address is still the same as the IP-address of the far end of the Ebgp session.
Therefore, the receiver of Ibgp updates will see the next-hop information indicating a destination that is not directly connected.
To resolve this problematic, the router will check its routing table and see how it can reach the next-hop address. The router can then route IP-packets with destination addresses matching the network in the BGP update; in the same direction as it would have routed an IP-packet with a destination address equal to the IP-address stated in the next-hop attribute. This process is known as recursive routing.
- So we should keep in mind that a router does not change BGP attributes when an update is sent across an Ibgp session, unless next-hop-self is configured.
When an Ebgp speaking router sends an update across an Ebgp session, the next-hop attribute is always set and the as-number of the router is prepended to the as-path attribute.
Ibgp uses split horizon to prevent routing information loops. Ebgp does not use split horizon and instead uses the as-path to detect loops.
In both cases, a router forwards only the best route and never sends a route back on the session from which it was received. However, Ibgp split-horizon rules also prohibit a router from forwarding any information that is received from an Ibgp session to another Ibgp session.
Below, there is an example of that situation. Figure A.5: next-hop setup within an Ibgp or Ebgp session
7. In figure A.5 above, ISP-B’s router updates RT-B about prefix 220.127.116.11/24.
The update overlays on an Ebgp session. The next-hop attribute is set to the IP-address that is used ISP-B’s router as a BGP neighbor/speaker: 18.104.22.168/32.
Reciprocally, RT-B will use this information to route packets to network 22.214.171.124/24 by forwarding them to ISP-B’s router. RT-B forwards the BGP updates over all its Ibgp sessions. The next-hop attribute is normally not changed on Ibgp updates.
But in this case, since we precise the “next-hop-self” instruction, set to the loopback interface of the ISIS session, RT-B also forwards the update on all its Ibgp sessions and changes the next-hop attribute to the IP-address of its own ISIS loopback interface.
As a result, RT-A and RT-C will get information that they can reach network 126.96.36.199/24 by forwarding packets to next-hop 188.8.131.52.
However, still, this IP-address is not directly connected. The routers will inspect the routing table to see if and how they can reach 184.108.40.206/24, they will, then route packets to network 220.127.116.11/24 in the same direction that they would use to route packets to 18.104.22.168/24.
RT-A also forwards the BGP updates of network 22.214.171.124/24 to Customer-C’s router. This is an Ebgp session, which means that RT-A will set the next-hop attribute to its own IP-address that is used on that Ebgp session, 126.96.36.199.