Short answer: BGP NEXT_HOP is the IP address a router recursively resolves to determine the forwarding path for a destination. A route can be present in BGP yet unusable if that address is unreachable. In iBGP, next-hop-self is commonly used to make the advertising router the reachable next hop.
What the BGP NEXT_HOP attribute does
NEXT_HOP is a well-known mandatory BGP path attribute. It identifies the next-hop IP associated with the advertised NLRI; the receiving router resolves that address through its routing table to determine the immediate forwarding adjacency and outgoing interface.[1]
This is distinct from the BGP TCP peer. A router may learn a route from one neighbor while forwarding toward a different next-hop address. BGP reachability and forwarding reachability are therefore related but separate checks.
Why next-hop reachability matters
Consider an edge router learning 203.0.113.0/24 from ISP-A. It advertises the route to an iBGP route reflector without changing NEXT_HOP. An internal router receives the path, but if it has no IGP or static route to the ISP-facing address, the BGP path cannot provide usable forwarding. The route may appear in the BGP table while being absent from the active routing/forwarding table.
RFC 4271 specifies that iBGP speakers normally do not modify NEXT_HOP for routes learned from another peer unless configured to announce their own address.[1]
When to use next-hop-self
Use it when the receiving iBGP router should forward traffic to the advertising router, and that router is reachable through the IGP or another underlay. It is often applied on route reflectors or distribution routers when clients should not need direct reachability to external peering addresses. Do not apply it blindly: changing the next hop can move traffic onto a router that lacks capacity, policy, or a valid route onward.
Configuration examples
Cisco IOS-style
router bgp 65010
neighbor 10.0.0.2 remote-as 65010
neighbor 10.0.0.2 next-hop-self
The command is applied per neighbor; confirm platform and address-family behavior in the device release documentation.[2]
FRRouting-style
router bgp 65010
neighbor 10.0.0.2 remote-as 65010
address-family ipv4 unicast
neighbor 10.0.0.2 next-hop-self
exit-address-family
Vendor-neutral intent: advertise eligible routes to that peer with the local BGP speaker's address as NEXT_HOP, then ensure that address is reachable in the peer's routing table.
Packet and route-policy walkthrough
- Edge R1 learns a prefix from ISP-A; its received NEXT_HOP is the ISP-facing address.
- R1 advertises that path to internal peer R2. Without next-hop-self, the original next hop is typically retained for iBGP.
- R2 recursively looks up the NEXT_HOP. If resolution succeeds, it forwards toward the resolved adjacency; if not, the path is unusable for forwarding.
- With next-hop-self on R1 toward R2, the advertised next hop becomes R1's address. R2 resolves R1 through the IGP and forwards packets to R1, which then forwards toward ISP-A.
Traffic-engineering impact—and limits
- Outbound control: NEXT_HOP directly affects the forwarding next-hop for traffic leaving the local router toward a selected BGP prefix. Reachability, IGP cost and competing paths influence the actual path.
- Inbound influence: Advertising a different reachable next hop can affect how a directly connected BGP neighbor forwards toward your advertised prefix, but it is not a reliable substitute for explicit inbound policy.
- What it cannot control: It cannot force remote ASes to select a particular route, override their policy, guarantee symmetric routing, or by itself provide reachability to the next-hop address. Local-pref, AS_PATH, MED, communities and provider policy may be more appropriate, depending on the direction and administrative boundary.
Modern use: WAN, EVPN/VXLAN and cloud edges
In a traditional WAN, next-hop-self can hide external link addresses from internal routers, provided the edge router remains the intended forwarding point. In route-reflector designs, it can simplify next-hop reachability but may concentrate transit traffic.
In BGP EVPN/VXLAN, distinguish the BGP transport next hop from the endpoint information carried by EVPN routes. The underlay must provide reachability to the relevant VTEP/next-hop addresses; changing BGP next-hop behavior without understanding the fabric's route type and forwarding model can break resolution or create an unintended path. In ACI-like or cloud/on-prem fabrics, follow the platform's documented control-plane and next-hop model rather than assuming classic WAN behavior.
Verification commands and expected logic
show ip bgp 203.0.113.0/24
show ip route 198.51.100.1
show ip cef 203.0.113.0/24
show ip bgp neighbors 10.0.0.2 advertised-routesCheck the selected path's NEXT_HOP, then confirm that the next-hop IP resolves through an active route and that the forwarding entry points to the intended interface/adjacency. On FRRouting, use show bgp ipv4 unicast 203.0.113.0/24, show ip route 198.51.100.1 and inspect the peer's advertised routes using the platform's available BGP commands.[3]
Troubleshooting checklist
- Is the prefix received, and what NEXT_HOP does the selected path show?
- Is there an active route to that next-hop IP in the correct VRF/address family?
- Does recursive resolution lead to the expected interface and adjacency?
- Is the route rejected or inactive because of next-hop resolution, policy, or a competing protocol route?
- Did an iBGP/route-reflector policy preserve the original next hop as expected?
- Would next-hop-self create a forwarding bottleneck or bypass firewall/NAT policy?
- For EVPN/VXLAN, is the underlay reachability to the advertised VTEP address intact?
Interview answer
“BGP NEXT_HOP identifies the address a router recursively resolves to forward traffic for a prefix. iBGP normally preserves a learned next hop; next-hop-self rewrites it to the advertising router so peers can resolve it through the IGP. I verify both the BGP path and the route/forwarding resolution for that address.”
Post a Comment