Hub-and-spoke, extranet and two customers

Theoretical foundations and architecture

Laboratory session: architecting advanced L3VPN topologies — Hub-and-Spoke, Extranet, and Shared Services. While basic L3VPN defaults to Any-to-Any (Full Mesh), enterprise compliance often mandates a Hub-and-Spoke topology: branch offices (Spokes) must never communicate directly; all inter-branch traffic must transit a centralized firewall at headquarters (Hub). This design is engineered purely via asymmetric Route Target policies: the Hub router deploys two VRFs or dual RTs (e.g., Hub-In 65000:10 and Hub-Out 65000:20). Spokes export with Hub-In and import solely Hub-Out (typically learning only a default 0.0.0.0/0 generated by the firewall). Direct spoke-to-spoke route leaking is blocked. The lab also configures Extranet / Shared Services, enabling controlled cross-VRF route importing between distinct customer tenants and central infrastructure services.

The RT as a topology constructor

The topology of an L3VPN is defined not by protocols but by a table of "who exports and imports which RT". MP-BGP carries all routes in the same way, and the VRF decides by RT which of them to accept. Three basic patterns:

Hub-and-spoke: why two VRFs on the hub PE

The goal is to force all inter-site traffic through the firewall of the hub site. If the hub PE has a single VRF with import 65000:10 and export 65000:20, a packet from spoke 1 to spoke 2 arrives at the hub PE with the VPN label of that VRF and the PE, finding a route to spoke 2 (it is imported), forwards it directly, bypassing the firewall. Therefore the hub PE is split into two VRFs with two PE-CE links to one CE (the firewall):

• HUB-IN (imports RT 65000:10): it holds the routes of all spokes; the PE hands them to the firewall over link 1, the firewall returns the inspected traffic to the same link, and the PE forwards it to the right spoke. The VRF exports nothing.
• HUB-OUT (exports RT 65000:20): it holds the routes received from the firewall over link 2 (the default and the hub-site LAN 192.168.10.0/24); their RT 65000:20 is imported by the spokes. Traffic from a spoke arrives with the HUB-OUT label and leaves over link 2 towards the firewall - this VRF has no other path.

Consequence: spoke-to-spoke traffic goes spoke 1 -> PE2 -> PE1 (HUB-OUT) -> firewall -> PE1 (HUB-IN) -> PE2 -> spoke 2; on PE1 the packet crosses a VRF twice in the data plane.

PE-CE protocol specifics on the hub

With eBGP between the hub PE and the firewall, all spokes usually share one AS: the hub CE and a spoke CE in the same AS 65101 will not accept each other's routes because of loop prevention. On the PE use as-override, or allowas-in on the CE. With static routing (as in the lab) there is no problem, but the firewall must have routes to the spoke LANs through the PE (link 1) and a default through the PE (link 2). Without a return route towards the spoke, traffic is lost at the firewall.

Extranet and shared services

Shared services (DNS, monitoring, a SaaS gateway) are placed in a separate VRF SS with RT 65000:900. Customer VRFs additionally import 65000:900, and SS imports the customer RTs so that a return route exists. Principles:

• Visibility is one-way at the route level but two-way at the packet level: customer routes are needed in SS for the reply, because SS has no default.
• Customer addresses entering SS must be unique: two customers with overlapping LANs imported into SS conflict (for such customers use NAT at the boundary or do not import the LAN, only the required /32s).
• Customers A and B do not import each other's RT: even with a shared SS they stay isolated as long as SS does not provide a transit default between VRFs.
• Limit the leak with explicit policies (import-map/vrf-import) so that SS receives not the whole table but only the required prefixes.

Cisco/Huawei/Junos: where the RT is set

Cisco and Huawei - declaratively in the VRF (route-target/vpn-target), Junos - vrf-target or vrf-import/vrf-export policies with communities. Policies are needed when the logic is more complex than "one RT": several RTs on import (spoke: 20 and 900), an RT for only part of the routes, prefix restrictions.

Convergence and scale

Every RT change causes route reselection in the VRF: on large tables use clear only for the affected VRFs. The number of RTs per VRF is limited (Huawei - up to 8 in one command, Cisco - dozens). The more complex the RT scheme, the harder the audit: keep the RT matrix (who exports, who imports) as data in Git.

Verifying the topology

The right check is not a ping but the routing table: a spoke VRF has no prefixes of other spokes (only the hub default, the hub-site LAN and the services), HUB-IN has all the spokes, SS has the spokes and no hub. A spoke-to-spoke traceroute must show the firewall, and a request to SS goes directly to PE1. Any other behavior is an RT leak.

Architecture Diagram & Topology

               [Hub CE / Firewall]
                        ^
                        | (Hub PE: VRF Hub-In imports RT 65000:10, VRF Hub-Out exports RT 65000:20)
                        v
                 [Provider Core]
                  /           \
                 v             v
          [Spoke-1 CE]     [Spoke-2 CE]
(Imports RT 65000:20 only)  (Imports RT 65000:20 only)
(Exports RT 65000:10)       (Exports RT 65000:10)

Traffic Flow & Label Stack Scheme

Hub-and-Spoke Routing Policy Enforcement:
1. Spoke-1 advertises 10.1.0.0/24 with Export RT 65000:10.
2. Spoke-2 imports only RT 65000:20, so it does not learn the Spoke-1 route directly.
3. Hub PE imports RT 65000:10 into VRF Hub-In and passes the spoke routes to the firewall.
4. VRF Hub-Out exports a default/summary route with RT 65000:20; the spokes import it.
5. Spoke-to-spoke traffic therefore follows the default route to the hub and is inspected by the firewall.

State & Parameter Comparison Table

Architectural model and principles

In real service provider networks, MPLS unifies equipment from multiple vendors. Below are practical configuration and operational verification examples across four platforms: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos, and MikroTik RouterOS v7. Pay close attention to syntax nuances and label distribution mechanisms.

Practical Configuration (Cisco, Huawei, Juniper, MikroTik)

Cisco (IOS-XE/XR)