Environment

• IPv6 eBGP session inside a VRF
• BGP update-source is an IPv6 VRRP VIP
• The same interface also carries an IPv4 address

Problem

The IPv6 BGP session remains Established and uses the correct IPv6 source address, but FRR’s cached global next hop becomes an IPv4-mapped IPv6 address:

Local host: 2001:db8:100::6, Local port: 38097
Foreign host: 2001:db8:100::1, Foreign port: 179
Nexthop: 192.0.2.10
Nexthop global: ::ffff:192.0.2.10

IPv6 routes are consequently advertised with that mapped address:

Prefix                         Nexthop
2001:db8:200:1::/64            ::ffff:192.0.2.10
2001:db8:200:2::/64            ::ffff:192.0.2.10
2001:db8:200:3::/64            ::ffff:192.0.2.10

The receiving Junos router then obviously rejects them:

Hidden reason: protocol nexthop is not on the interface

The local routes themselves have an unspecified next hop (::) and the BGP TCP session is correctly sourced from 2001:db8:100::6, so the wrong address appears to be introduced during outbound UPDATE generation.

Attempted mitigation

An outbound route-map was applied:

route-map: FORCE-V6-NH
permit, sequence 10 Invoked 9
 Set clauses:
  ipv6 next-hop global 2001:db8:100::6

A soft outbound reset was performed, but the peer continued receiving ::ffff:192.0.2.10. Therefore, an explicit set
ipv6 next-hop global does not override the corrupted cached value.

A hard neighbor reset immediately corrected the problem, with or without the route-map:

Nexthop global: 2001:db8:100::6

Workaround

Hard-reset affected IPv6 neighbors:

vtysh -c 'clear bgp vrf TENANT ipv6 2001:db8:100::1'

A soft reset is insufficient. Ideally, FRR should refresh the cached global next hop when the VRRP address returns,
and an explicit outbound next-hop route-map should take precedence over an IPv4-mapped cached value.