External BGP MPLS L3 VPN (VPNv4) route advertisement

Note

This section covers MPLS L3 VPN (VPNv4 / VPN-IPv4), for example, Cisco show bgp vpnv4 unicast all or Juniper bgp.l3vpn.0. EVPN (BGP family l2vpn-evpn) peering and route advertisement are a different BGP family and are not subject of this section.

When a data-center border router establishes an eBGP MPLS L3 VPN session to OpenSDN control nodes, the peer typically receives a large set of RD:IPv4-prefix Network Layer Reachability Information (NLRI) entries. Each route distinguisher (RD) value identifies a virtual-network routing instance inside the OpenSDN fabric. Route targets attached to those NLRIs describe how MPLS L3 VPN routes are distributed inside the MP-BGP control plane.

This behavior is expected in common MPLS L3 VPN designs where OpenSDN control nodes participate in MP-BGP as route reflectors for tenant virtual networks. It reflects control-plane visibility of MPLS L3 VPN routes, not proof that the border router can forward into every tenant overlay.

What an external peer typically receives

After eBGP peering is established between a border router and OpenSDN control nodes, the external peer may observe:

Many VPNv4 prefixes in the form RD:IPv4-prefix (BGP inet-vpn NLRI).
Route targets that OpenSDN auto-assigns to virtual networks. In typical deployments, route-target values use the cluster autonomous system (AS) and local administrator values (commonly ≥ 8,000,000 for auto-generated targets in a default AS such as 64512).
A VPNv4 RIB size that grows with the number of virtual networks and routes exported from the fabric routing instances.

A large bgp.l3vpn.0 table on the peer can be normal and does not by itself mean that virtual networks are datapath-reachable from the border.

Control-plane visibility vs forwarding

OpenSDN internal virtual-network routes that appear in the fabric MPLS L3 VPN control plane may carry attributes that make them non-forwardable from the border, such as no-forward or otherwise unusable next hops on the fabric side. The border may learn many VPNv4 prefixes while only a subset is usable for forwarding, depending on route targets, import policy on the peer, encapsulation, and how the border is attached to the fabric.

Do not assume that because a prefix is visible in the peer VPNv4 RIB the border can reach the corresponding tenant network unless you have verified forwarding for your documented topology, for example, matching route targets, supported encapsulation, and gateway placement.

Configuration surfaces that do not filter fabric VPNv4 export

Operators sometimes expect virtual-network routing policies, used to control inter-virtual-network route leaks and secondary MP-BGP paths, to act like selective export policy toward an external eBGP neighbor on the fabric VPNv4 RIB. That expectation does not match OpenSDN behavior:

Virtual network routing policies primarily govern route exchange between virtual-network routing instances inside OpenSDN, not selective export from the internal fabric MPLS L3 VPN RIB to an arbitrary external BGP peer.
Route targets identify membership in the MPLS L3 VPN control plane. They are not a per-neighbor export filter on the inet-vpn session to a border router.
Logical router export policies and similar constructs serve other OpenSDN use cases and likewise do not provide advertise only these MPLS L3 VPN prefixes to this eBGP neighbor semantics on the fabric VPNv4 RIB comparable to selective PE export on a traditional carrier edge.

This is known upstream OpenSDN behavior. MOSK documents this so architects can plan border integration without treating full VPNv4 RIB visibility as an undocumented defect.

Planning for border integration

When integrating OpenSDN with an external border gateway:

Treat a large VPNv4 RIB on the peer as possible expected control-plane behavior after peering with OpenSDN control nodes.
Apply import, route-target, and prefix filtering on the border (or on intermediate route reflectors) if the design requires limiting which MPLS L3 VPN prefixes are accepted or used.
Do not rely on virtual network routing policy alone to restrict what the border receives on the VPNv4 session.
Validate encapsulation and ASN settings consistently with OpenSDN.