BGPaaS: Agent should resolve v4-mapped v6 NH for IPv6 prefix announced via MP-BGP over v4 transport

Bug #1534786 reported by amit surana
6
This bug affects 1 person
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).

Tags: bgpaas vrouter
amit surana (asurana-t)
description: updated
Revision history for this message
Nischal Sheth (nsheth) wrote :

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.

Revision history for this message
Nischal Sheth (nsheth) wrote :
Nischal Sheth (nsheth)
Changed in juniperopenstack:
status: New → Won't Fix
status: Won't Fix → Invalid
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.