Virtual Hub-and-Spoke in BGP/MPLS VPNs
Extracted elements (31)
The document uses distinct RDs per V-hub for the VPN-IP default route so that a V-spoke importing multiple default routes (one per V-hub) can load-share outbound traffic across V-hubs when all routes have equal preference, without requiring any per-prefix state at the V-spoke.
The V-hub/V-spoke architecture may reduce ingress replication bandwidth by having V-spokes replicate only to their V-hub(s), and having each V-hub replicate only to its associated V-spokes, rather than every PE replicating to all others. This is especially beneficial when V-spoke PEs have limited replication capability or bandwidth.
To handle multihomed CE sites connected to both a V-hub and a V-spoke, two options are described: (1) prohibit provisioning such PEs as V-spokes, or (2) have the V-spoke not install CE routes in its forwarding table but re-advertise them with MPLS labels pointing to the CE, forcing all inter-spoke traffic through the V-hub. Implementations supporting IBGP/EBGP load balancing SHOULD support option 2.
V-spokes are provisioned to import only routes carrying a specific RT-VH; adding a new V-spoke requires provisioning only on that V-spoke — no changes to the V-hub are required. This one-sided provisioning model simplifies scaling the spoke population.
When a V-spoke PE has Internet connectivity via a CE advertising an IP default route, the V-spoke must not advertise an IP default back to that CE (which would cause a loop); the CE is instead required to use the V-spoke as next-hop for all VPN traffic, relying on the VPN-IP default from the V-hub for routing within the VPN.
A given V-hub and its associated V-spoke(s) MUST be in the same Autonomous System. When VPN VRFs span multiple ASes, V-hubs may be spread across ASes, but the hub-spoke pairing is intra-AS only.
The multicast procedures assume all PEs can discard packets from a 'wrong' PE per RFC 6513 Section 9.1.1. Existing S-PMSI/I-PMSI procedures suffice for all P-tunnel types except Ingress Replication on I-PMSI, for which Section 7.9 adds new label-based demultiplexing procedures.
A PE receiving an I-PMSI A-D route with Leaf Information Required=1 MUST respond with a Leaf A-D route whose PMSI Tunnel attribute carries Tunnel Type = Ingress Replication, a routable PE address as Tunnel Identifier, and a downstream-assigned MPLS label that enables the receiving PE to identify both the VRF and the sending PE.
A V-hub MUST NOT import a VPN-IP default route unless the imported route is the Internet VPN-IP default route, preventing routing loops where V-hubs forward traffic back toward each other via default routes.
A V-hub of a given VPN MUST export a VPN-IP default route for that VPN, and this route MUST be exported only to the V-spokes of that VPN that are associated with that V-hub.
An implementation MUST support the first Internet connectivity alternative: a PE maintaining Internet routes also maintains a VPN VRF, with a provisioned default route pointing to the Internet routing table; this PE must not be a V-spoke.
In Case 1 (received I-PMSI/S-PMSI A-D route carries the receiving V-hub's RT-VH), the V-hub MUST NOT forward traffic received on that P-tunnel to any other V-hubs or V-spokes, including its own associated V-spokes, preventing multicast duplication.
In Case 2 (received I-PMSI/S-PMSI A-D route does not carry the receiving V-hub's RT-VH), when the V-hub accepts an S-PMSI or SA A-D route, it MUST reoriginate the route targeted to its V-spokes by replacing the RT(s) with RT-VH, updating the RD, Next Hop, and (for S-PMSI) the Originating Router's IP address and PMSI Tunnel attribute.
RT-VH MUST be different from the export RT-VPN provisioned on that V-hub, and no two VPNs served by a given provider can use the same RT-VH, ensuring unique route-target-based scoping.
The MPLS label that a V-hub advertises with a VPN-IP default route MUST be mapped to an NHLFE that identifies the VRF of the V-hub, so that upon receiving a labeled packet the V-hub pops the label and performs a VRF lookup for further disposition.
To enable load sharing among V-hubs, each V-hub MUST use a distinct RD (per V-hub, per VPN) when originating a VPN-IP default route. The use of Type 1 RDs is noted as an attractive option.
When a V-hub originates a non-Internet VPN-IP default route, the V-hub MUST attach RT-VH (not RT-VPN) to that route so that only associated V-spokes import it, while other V-hubs and vanilla PEs do not.
When a V-hub originates a VPN-IP default route, it MUST NOT install an IP default route in its own VRF unless: (a) a CE advertises an IP default route to it, (b) it receives and imports the Internet VPN-IP default route, or (c) the VRF is provisioned with a default pointing to the Internet routing table.
When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the route MUST also carry RT-VH (the RT of the V-hub's VPN-IP default route), in addition to RTs constructed per RFC 6514/6625, so that associated V-spokes also import these multicast routes.
When a V-hub originates the Internet VPN-IP default route, it MUST withdraw any non-Internet VPN-IP default route it had originated; conversely, when the Internet VPN-IP default route is withdrawn, the V-hub MUST re-originate a non-Internet VPN-IP default route. At any time, a V-hub originates exactly one of these two.
When a V-spoke receives an IP default route from a CE, it MUST NOT install that route as an IP default in its VRF; instead it MUST originate a VPN-IP default route carrying only RT-VPN with an MPLS label whose NHLFE next-hop points directly to that CE.
When Ingress Replication is used for I-PMSI P-tunnels in an MVPN with V-hub/V-spoke PEs, the PMSI Tunnel attribute in the I-PMSI A-D route MUST set Tunnel Type to Ingress Replication, MUST set the Leaf Information Required flag to 1, and MUST carry no MPLS labels.
When originating a VPN-IP default route for multicast support, a V-hub MUST add the VRF Route Import Extended Community embedding the V-hub's IP address and MUST include the Source AS extended community, per RFC 6514 Sections 6 and 7.
Within a given VPN, a V-spoke MUST import all VPN-IP default routes that have been originated by the V-hubs associated with that V-spoke, ensuring the V-spoke has a path to all other VPN sites via its V-hub(s).
A V-hub MUST originate two I-PMSI A-D routes: a standard 'vanilla' I-PMSI A-D route and an 'Associated-V-spoke-only I-PMSI A-D route' carrying only RT-VH. The latter carries traffic from other V-hubs, non-associated V-spokes, and vanilla PEs to the V-spokes associated with this V-hub. Each MUST use a distinct RD.
A Virtual Hub (V-hub) is a PE that maintains all routes of a given VPN by importing routes from all other V-hubs, V-spokes, and vanilla PEs of that VPN. A Virtual Spoke (V-spoke) needs to maintain only routes originated by its own connected sites plus VPN-IP default routes from its associated V-hub(s), enabling a two-level hierarchy that reduces per-PE routing state.
A VPN-IP default route is defined as a VPN-IP route whose VPN-IP prefix contains only a Route Distinguisher (RD) — no host or network prefix bits beyond the RD. V-hubs originate these routes to give V-spokes a next-hop of last resort for all VPN destinations.
Each V-hub is provisioned with a unique per-VPN export Route Target called RT-VH, in addition to the shared RT-VPN carried on all VPN-IP routes. RT-VH is attached to VPN-IP default routes and I-PMSI/S-PMSI/SA A-D routes to restrict their import to only the V-spokes associated with that V-hub.
On a V-spoke, the set of Eligible Upstream Multicast Hop (UMH) routes consists of all unicast VPN-IP routes received by the V-spoke, including VPN-IP default routes from its V-hub(s) and optionally routes from peer V-spokes, using SAFI 128 (MPLS-labeled VPN) or SAFI 129 (Multicast for BGP/MPLS IP VPNs).
The Internet VPN-IP default route is distinguished from a non-Internet VPN-IP default route by its RT set: for a given V-hub, the Internet variant carries both RT-VPN and RT-VH (allowing import by other V-hubs), while the non-Internet variant carries only RT-VH (imported exclusively by associated V-spokes).
This document introduces no new security considerations beyond those already specified in RFC 4364 (BGP/MPLS IP VPNs). All existing VPN security properties — PE-to-PE tunnel security, VRF isolation, and RT-based route filtering — apply without modification.