By default, IPv4 routes are advertised with IPv4 next-hops but on IPv6-TCP transport sessions they can be advertised with IPv6 next-hops if the advertise-ipv6-next-hops command (with the IPv4 option) applies to the session. To receive IPv4 routes with IPv6 next-hop addresses from a peer, the extended-nh-encoding command (with the IPv4 option) must be applied to the session. This advertises the corresponding RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop, capability to the peer.
Whenever next-hop-self applies to an IPv4 route, the next hop is set as follows.
If the peer whose routes are being advertised is an IPv4 transport peer (in other words, the neighbor address is IPv4), the BGP next-hop is the IPv4 local address used to setup the session.
If the peer toward which the routes are being advertised is an IPv6 transport peer (in other words, the neighbor address is IPv6), and the advertise-ipv6-next-hops command (with the ipv4 option) applies to the session, and the peer toward which the routes are being advertised opened the session by announcing an Extended NH Encoding capability for AFI =1, SAFI = 1 and next-hop AFI = 2, then the BGP next-hop is the IPv6 local address used to setup the session. Otherwise, for all other cases, the BGP next-hop is the IPv4 address of the system interface. If the system interface does not have an IPv4 address, the route is not advertised unless an export policy sets a valid IPv4 next-hop.
When an IPv4 BGP route is advertised to an EBGP peer, next-hop-self always applies except if the third-party-nexthop command is applied. Configuring third-party-nexthop allows an IPv4 route received from one EBGP peer to be advertised to another EBGP that is in the same IP subnet with an unchanged BGP next-hop.
When an IPv4 BGP route is re-advertised to an IBGP or confederation EBGP peer, the advertising router does not modify the BGP next-hop unless one of the following applies.
The BGP next-hop-self command is applied to the IBGP or confederation EBGP peer. This causes next-hop-self to be applied to all IPv4 routes advertised to the peer, regardless of the peer type from which they were received (IBGP, confed-EBGP, or EBGP).
IPv4 routes are matched and accepted by a route policy entry, and this entry has a next-hop-self action. This applies next-hop-self as described above to only those routes matched by the policy entry.
IPv4 routes are matched and accepted by route policy entry, and this entry has a next-hop ip-address action. This changes the BGP next-hop of only the matched routes to the ip-address, if the ip-address is an IPv4 address or if the ip-address is an IPv6 address and the necessary conditions exist. The advertise-ipv6-next-hops command is configured appropriately and the peer opened the session with the correct RFC 5549 capability.
When an IPv4 BGP route is locally originated and advertised to an IBGP or confederation EBGP peer, the BGP next-hop is, by default, copied from the next hop of the route that was imported into BGP, with specified exceptions (for example, black-hole next-hop). When a static route with indirect next hop is re-advertised as a BGP route, the BGP next-hop is a copy of the indirect address. However, with route table import policies, BGP can be instructed to take the resolved next hop of the static route as the BGP next-hop address.