BGPaaS: Agent should resolve v4-mapped v6 NH for IPv6 prefix announced via MP-BGP over v4 transport
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Juniper Openstack |
Won't Fix
|
Medium
|
Manish Singh | ||
Trunk |
Won't Fix
|
Medium
|
Manish Singh |
Bug Description
IPv6 prefixes announced via MP-BGP running over IPv4 transport, have a v4-mapped v6 NH of the form ::ffff:<IPv4 address>. The IPv4 address portion of the NH is the local address used by the TCP connection for BGP peering. Currently, agent does not have logic to resolve this NH, and as such the routes remain unusable.
A possible workaround is for the user to configure a BGP policy to change the NH of the advertised route to the native IPv6 address of the vif (v6 address assigned by neutron). Since agent has knowledge of this native v6 address, path resolution can be done and the routes can be used.
In the absence of such a workaround, it would be desirable to have agent deal with the v4-mapped v6 NH, by perhaps generating v4-mapped v6 addresses for VMIs that have the BGPaaS object reference (only for the configured/primary instance-ip attached to the VMI).
description: | updated |
Changed in juniperopenstack: | |
status: | New → Won't Fix |
status: | Won't Fix → Invalid |
status: | New → Won't Fix |
On further thought I think it would be better to teach the control node
to resolve v4 nexthops for v6 routes. A v4-mapped-v6 nexthop for a v6
route should be treated as a v4 nexthop. The CN should then be able to
resolve this v4 nexthop for a v6 route.