To use a BGP route for forwarding, a BGP router must know how to reach the BGP next-hop of the route. The process of determining the local interface or tunnel used to reach the BGP next-hop is called next-hop resolution. The BGP next-hop resolution process depends on the type of route (the AFI/SAFI) and various configuration settings.
The following procedures apply to the next-hop resolution of IPv4 and IPv6 (unlabeled) unicast routes.
When an IPv6 route is received with an IPv4-mapped IPv6 address as next-hop, BGP next-hop resolution is based on the embedded IPv4 address and this IPv4 address is matched to IPv4 routes or IPv4 tunnels, depending on configuration. The IPv4-mapped IPv6 address is never interpreted as an IPv6 address to be compared to IPv6 routes or IPv6 tunnels.
BGP routes are eligible to resolve a BGP next-hop only if the use-bgp-routes command is configured. A maximum of four levels of recursion are supported.
If there are multiple eligible routes that match the BGP next-hop, the longest prefix match (LPM) route is selected.
If the LPM route is rejected by the user-configured next-hop-resolution policy or if there are no eligible matching routes, the BGP next-hop is unresolved and all the routes with that next-hop are considered invalid and not advertised to peers.
BGP shortcuts are described in Next-hop resolution of BGP unlabeled IPv4 unicast routes to tunnels.
The following procedures apply to the next-hop resolution of VPN-IPv4 and VPN-IPv6 routes.
When an VPN-IPv4 or VPN-IPv6 route is received with an IPv4-mapped IPv6 address as next-hop, BGP next-hop resolution is based on the embedded IPv4 address and this IPv4 address is matched to IPv4 routes and/or IPv4 tunnels, depending on configuration. The IPv4-mapped IPv6 address is never interpreted as an IPv6 address to be compared to IPv6 routes or IPv6 tunnels.
If the VPN-IP route is imported into a VPRN, the next-hop is resolved to a tunnel based on the auto-bind-tunnel configuration of the importing VPRN. For more information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN.
If the next-hop entry in the tunnel-table that resolves the VPN-IP route is rejected by the user-configured next-hop-resolution vpn-family-policy, the BGP next hop is unresolved and all the VPN-IP routes with that next hop are considered invalid.
If the VPN-IP route is received from an IBGP or EBGP peer, and the router is a next-hop-self RR or a model-B ASBR, the order of resolution is as follows:
local (interface) route
longest prefix-match static route, excluding default static routes, but only if allow-static is configured
tunnel, based on the transport-tunnel resolution-filter options for family VPN; for more information, see Next-hop resolution of BGP labeled routes to tunnels
The following procedures apply to the next-hop resolution of EVPN routes.
If an EVPN ES route is imported, the next hop is resolved to any tunnel in the tunnel-table. If there is no entry matching the next hop in the tunnel-table, a route matching the next hop in the route-table also resolves the next hop.
If the resolving route in the tunnel-table or the route-table is rejected by a user-configured next-hop-resolution vpn-family-policy, the ES route's next hop is unresolved.
If the ES route next hop is unresolved, the PE that advertised the route is not considered as candidate for Designated Forwarder (DF) election.
The imported AD per-ES and AD per-EVI routes are always shown as resolved and valid, irrespective of the next-hop resolution or the configuration of a next-hop-resolution vpn-family-policy.
With DF election, the router always considers the advertising PE a valid candidate, even if the AD routes next hops are unresolved.
However, if the AD per-EVI next hop is unresolved, EVPN traffic is not sent to the advertising PE. This is true for EVPN VPWS or multi-homing aliasing or backup procedures.
A matching tunnel-table entry can resolve the next-hop of an AD per-EVI route in an EVPN-MPLS service. A route-table entry (other than a shortcut) can resolve the AD per-EVI route next-hop in an EVPN-VXLAN service.
For any other imported EVPN service route, including IP prefix, IPv6 prefix, MAC/IP, Inclusive Multicast (IMET) and Selective Multicast (SMET) routes, the next hop is resolved as follows.
In EVPN-MPLS services, the next hop is resolved to a tunnel based on the auto-bind-tunnel configuration of the importing service.
In EVPN-VXLAN services, the next hop is resolved to a route in the route-table. That route cannot be a shortcut route.
If the next-hop entry in the tunnel-table or route-table that resolves the EVPN service route is rejected by the user-configured next-hop-resolution vpn-family-policy, the BGP next hop is unresolved and all the EVPN routes with that next hop are considered invalid.
The following procedures apply to the next-hop resolution of label-unicast IPv4 and label-unicast IPv6 routes.
When a BGP-LU route is received with an IPv4-mapped IPv6 address as the next-hop, BGP next-hop resolution is based on the embedded IPv4 address and this IPv4 address is matched to IPv4 routes or IPv4 tunnels, depending on the configuration. The IPv4-mapped IPv6 address is never interpreted as an IPv6 address to be compared to IPv6 routes or IPv6 tunnels.
If the BGP-LU route is received by a control-plane-only RR with the disable-route-table-install and rr-use-route-table commands configured, the order of resolution is as follows:
the local route
the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with blackhole next-hop. For other types of static routes, use this route to resolve the next-hop only if allow-static is configured. If it is another type of static route, use it to resolve the next-hop only if allow-static is configured.
the longest prefix-match IGP route
If a label-unicast IPv4 route or label-unicast IPv6 route with a label (other than explicit-null) is received from an IBGP or EBGP peer and the router is not an RR with the rr-use-route-table command configured, the order of resolution is as follows:
the local route
the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with a blackhole next-hop. If it is another type of static route, use it to resolve the next-hop only if allow-static is configured.
a tunnel, based on the transport-tunnel resolution-filter options for family label-ipv4 or label-ipv6 (depending on the situation); for more information, see Next-hop resolution of BGP labeled routes to tunnels
If a label-unicast IPv6 route with an IPv6 explicit-null label is received from an IBGP or EBGP peer and the router is not an RR with the rr-use-route-table command configured, the order of resolution is as follows:
the local route
the longest prefix-match static route, excluding default static routes
Use this route to resolve the BGP next-hop if it is a static route with a a blackhole next-hop. If it is another type of static route, use it to resolve the next-hop only if allow-static is configured
a tunnel, based on the transport-tunnel resolution-filter options for family label-ipv4; for more information, see Next-hop resolution of BGP labeled routes to tunnels
if configure>router>bgp>next-hop-resolution>labeled-routes>use-bgp-routes>label-ipv6-explicit-null is enabled and if the longest prefix length route that matches the next-hop is a BGP IPv4 unlabeled, BGP IPv6 unlabeled, or other 6PE route with an explicit-null label, then use that route, subject to the following conditions:
the resolving route cannot be a leaked route
an unlabeled IPv4 route or IPv6 route is ineligible to resolve the next-hop of a label-unicast IPv6 route if the unlabeled route has any of its own BGP next-hops resolved by an IGP route or a 6over4 route
the label-unicast IPv6 route can be recursively resolved by other label-unicast IPv6 routes with explicit-null so that the final route has up to four levels of recursion