Non-VPN transit provider is another method in inter-provider MPLS VPNs used when service providers are not directly connected but link through a transit MPLS provider that does not offer VPN services, enabling end-to-end LSPs between PE routers.
Non-VPN Transit Provider Example in Inter-Provider MPLS VPNs
A non-VPN transit provider is used in inter-provider MPLS VPNs when service providers are not directly connected. Instead, they connect through a transit provider that does not offer VPN services.
In the control plane, this works like Multi-Hop MP-eBGP Between Route Reflectors. Multi-hop MP-eBGP sessions are established between the route reflectors (RRs) of different MPLS VPN providers, exchanging customer VPNv4 routes without changing the next-hop, so that end-to-end LSPs between PE routers are maintained.
This is achieved by establishing IPv4 BGP sessions between the MPLS VPN service providers and the transit provider, with BGP send-label enabled. The transit provider advertises the required routes, assigns MPLS labels, and ensures reachability between RRs and PEs, enabling end-to-end LSPs across different providers.
Understanding the Topology of Inter-Provider MPLS VPNs with a Transit Provider
This topology helps explain the non-VPN transit provider scenario in inter-provider MPLS VPNs.
We have two MPLS VPN service providers with different autonomous systems, AS1 and AS2, which are not directly connected. Instead, they are connected through a non-VPN MPLS transit provider with AS number AS100.
Two customers, A and B, are distributed across both service providers. Customer sites A1 and B1 are connected to the first service provider via PE11, while A2 and B2 are connected to the second service provider via PE21.
In each service provider, a route reflector is used: P11 in AS1 and P21 in AS2. These route reflectors exchange customer routes by advertising VPNv4 routes using multi-hop MP-eBGP between the service providers. The route reflectors are configured not to change the next-hop, so from the perspective of PE11, the next-hop to reach A2 and B2 is the destination PE (PE21), and vice versa.
To support this, PE routers and route reflectors must be able to reach each other, and an end-to-end LSP must exist between the source and destination PE routers. This is achieved by advertising the loopback addresses of PEs and route reflectors using IPv4 eBGP between the service providers and the transit provider. BGP label distribution (send-label) is enabled so labels are assigned and advertised for these routes, since LDP does not assign labels to BGP-learned routes.
Key Configurations for PE, RR, and Transit Devices in MPLS VPNs
The following configurations represent the most important parts of some sample devices in the topology and help illustrate how the non-VPN transit provider mechanism works in inter-provider MPLS VPNs.
This configuration shows P11 acting as a route reflector in AS65001, forming an internal iBGP session with its PE and a multi-hop MP-eBGP VPNv4 session with the route reflector in AS65002 using loopback addresses. The vpnv4 address family is used to exchange customer routes, with extended communities enabled and next-hop unchanged so that VPN traffic points directly to the destination PE, preserving end-to-end LSPs. The use of ebgp-multihop allows the VPNv4 exchange across the non-VPN transit provider, enabling inter-provider MPLS VPN connectivity without a direct link between service providers.
# P11 router bgp 65001 no bgp default route-target filter neighbor 10.10.1.1 remote-as 65001 neighbor 10.10.1.1 update-source Loopback0 neighbor 10.10.2.11 remote-as 65002 neighbor 10.10.2.11 ebgp-multihop 255 neighbor 10.10.2.11 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.1.1 activate neighbor 10.10.1.1 send-community both neighbor 10.10.1.1 route-reflector-client neighbor 10.10.2.11 activate neighbor 10.10.2.11 send-community both neighbor 10.10.2.11 next-hop-unchanged exit-address-family
This configuration shows PE11 in AS65001 hosting multiple VRFs (A and B), assigning route distinguishers and route targets to separate and control customer routing. PE11 advertises customer routes into the MPLS VPN by redistributing connected and static routes into BGP and sending VPNv4 routes to its route reflector (P11). The next-hop-self setting ensures PE11 is the VPN next hop for local customer routes, while route reflectors later preserve the next hop across providers, enabling customer reachability and end-to-end LSPs in the inter-provider MPLS VPN environment.
# PE11 ip vrf A rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf B rd 1:200 route-target export 1:200 route-target import 1:200 ! router bgp 65001 bgp log-neighbor-changes redistribute connected redistribute static neighbor 10.10.1.11 remote-as 65001 neighbor 10.10.1.11 update-source Loopback0 neighbor 10.10.1.11 route-reflector-client ! address-family vpnv4 neighbor 10.10.1.11 activate neighbor 10.10.1.11 send-community both neighbor 10.10.1.11 next-hop-self exit-address-family ! address-family ipv4 vrf A redistribute connected redistribute static exit-address-family ! address-family ipv4 vrf B redistribute connected redistribute static exit-address-family ! ip route vrf A 192.168.1.0 255.255.255.0 Ethernet0/1 172.16.11.2 ip route vrf B 192.168.1.0 255.255.255.0 Ethernet0/2 172.16.12.2
This configuration shows ASBR11 in AS65001 connecting to the neighboring service provider via IPv4 eBGP with BGP send-label enabled, allowing labeled reachability to remote PE and route reflector loopbacks. Selected loopback routes from the remote provider are redistributed into OSPF so they are reachable within the MPLS core, while mpls bgp forwarding ensures labeled packets learned via BGP can be forwarded through the network. This setup enables PE routers and route reflectors in different providers to reach each other and supports the establishment of end-to-end LSPs across the non-VPN transit provider, which is essential for inter-provider MPLS VPN operation.
# ASBR11 interface Ethernet0/1 ip address 10.12.1.2 255.255.255.0 mpls bgp forwarding ! router ospf 1 redistribute bgp 65001 subnets route-map AS2_LP0 passive-interface Ethernet0/1 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 65001 bgp log-neighbor-changes network 10.10.1.1 mask 255.255.255.255 network 10.10.1.11 mask 255.255.255.255 neighbor 10.12.1.2 remote-as 65002 neighbor 10.12.1.2 send-label ! ip prefix-list AS2_LP0 seq 5 permit 10.10.2.1/32 ip prefix-list AS2_LP0 seq 10 permit 10.10.2.11/32 ! route-map AS2_LP0 permit 10 match ip address prefix-list AS2_LP0
This configuration shows PE101 in the non-VPN transit provider (AS65100) enabling labeled IPv4 transport between service providers. OSPF is used inside the transit network, while BGP with send-label exchanges selected PE and route reflector loopback routes with AS65001, assigning MPLS labels for BGP-learned prefixes. mpls bgp forwarding allows these labeled routes to be forwarded through the transit core, while LDP handles internal label distribution. Together, this ensures reachability between PEs and route reflectors across providers and enables end-to-end LSPs required for inter-provider MPLS VPN connectivity.
# PE101 router ospf 1 redistribute bgp 65100 subnets passive-interface Ethernet0/1 network 10.0.0.0 0.255.255.255 area 0 ! mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Ethernet0/0 ip address 10.100.1.1 255.255.255.0 mpls ip ! interface Ethernet0/1 ip address 10.12.1.1 255.255.255.0 mpls bgp forwarding ! ip prefix-list AS_1_2_LP0 seq 5 permit 10.10.1.1/32 ip prefix-list AS_1_2_LP0 seq 10 permit 10.10.1.11/32 ip prefix-list AS_1_2_LP0 seq 15 permit 10.10.2.1/32 ip prefix-list AS_1_2_LP0 seq 20 permit 10.10.2.11/32 ! route-map AS_1_2_LP0 permit 10 match ip address prefix-list AS_1_2_LP0 ! router bgp 65100 bgp log-neighbor-changes redistribute ospf 1 match internal external 1 external 2 route-map AS_1_2_LP0 neighbor 10.12.1.2 remote-as 65001 neighbor 10.12.1.2 send-label
Control Plane Overview: MP-eBGP, Route Reflectors, and VPNv4 Route Exchange
These outputs confirm that an end-to-end MPLS LSP exists between PE11 (10.10.1.1 in AS1) and PE21 (10.10.2.1 in AS2) across the non-VPN transit provider.
On ASBR11, IPv4 BGP with send-label installs labeled routes toward the remote PE loopback 10.10.2.1, showing an outgoing label assigned by the transit provider. These labeled routes are redistributed into the IGP, making the remote PE loopback reachable from PE11. The routing tables on PE11 and PE21 confirm mutual reachability of each other’s loopback addresses, which proves that labeled transport paths are in place and that traffic can be forwarded using MPLS labels end-to-end between the two PE routers.
ASBR11#show ip bgp
BGP table version is 31, local router ID is 10.10.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.1/32 10.1.2.1 21 32768 i
*> 10.10.1.11/32 10.1.2.1 11 32768 i
*> 10.10.2.1/32 10.12.1.1 1 0 65100 ?
*> 10.10.2.11/32 10.12.1.1 1 0 65100 ?
ASBR11#show ip bgp labels Network Next Hop In label/Out label 10.10.1.1/32 10.1.2.1 20/nolabel 10.10.1.11/32 10.1.2.1 19/nolabel 10.10.2.1/32 10.12.1.1 nolabel/21 10.10.2.11/32 10.12.1.1 nolabel/22
PE11#show ip route
...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Ethernet0/0
L 10.1.1.2/32 is directly connected, Ethernet0/0
O 10.1.2.0/24 [110/20] via 10.1.1.1, 05:43:10, Ethernet0/0
C 10.10.1.1/32 is directly connected, Loopback0
O 10.10.1.2/32 [110/21] via 10.1.1.1, 05:43:00, Ethernet0/0
O 10.10.1.11/32 [110/11] via 10.1.1.1, 05:43:10, Ethernet0/0
O E2 10.10.2.1/32 [110/1] via 10.1.1.1, 01:03:42, Ethernet0/0
O E2 10.10.2.11/32 [110/1] via 10.1.1.1, 01:03:42, Ethernet0/0
O 10.12.1.0/24 [110/30] via 10.1.1.1, 05:43:00, Ethernet0/0
PE21#show ip route
...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C 10.2.1.0/24 is directly connected, Ethernet0/0
L 10.2.1.2/32 is directly connected, Ethernet0/0
O 10.2.2.0/24 [110/20] via 10.2.1.1, 05:44:26, Ethernet0/0
O E2 10.10.1.1/32 [110/1] via 10.2.1.1, 01:05:03, Ethernet0/0
O E2 10.10.1.11/32 [110/1] via 10.2.1.1, 02:51:47, Ethernet0/0
C 10.10.2.1/32 is directly connected, Loopback0
O 10.10.2.2/32 [110/21] via 10.2.1.1, 05:44:26, Ethernet0/0
O 10.10.2.11/32 [110/11] via 10.2.1.1, 05:44:26, Ethernet0/0
O 10.12.2.0/24 [110/30] via 10.2.1.1, 05:44:26, Ethernet0/0
These outputs confirm that customer VPNv4 routes are correctly exchanged across service providers and installed on PE11 with the proper VPN label. On P11, the VPNv4 route for A2 (172.16.21.0/24) is learned via MP-eBGP from AS65002 with the next hop set to the remote PE loopback 10.10.2.1, showing that the route reflector preserves the destination PE as the next hop. PE11 receives this VPNv4 route and installs it in VRF A, where the label output confirms that traffic toward 172.16.21.0/24 is pushed with VPN label 23 and forwarded to PE21 (10.10.2.1). This verifies that customer routes are correctly advertised across providers and that VPN traffic from A1 to A2 uses the expected VPN label over the established end-to-end LSP.
P11#show bgp vpnv4 unicast all
BGP table version is 33, local router ID is 10.10.1.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*>i 172.16.11.0/24 10.10.1.1 0 100 0 ?
*> 172.16.21.0/24 10.10.2.1 0 65002 ?
*>i 192.168.1.0 10.10.1.1 0 100 0 ?
*> 192.168.2.0 10.10.2.1 0 65002 ?
Route Distinguisher: 1:200
*>i 172.16.12.0/24 10.10.1.1 0 100 0 ?
*> 172.16.22.0/24 10.10.2.1 0 65002 ?
*>i 192.168.1.0 10.10.1.1 0 100 0 ?
*> 192.168.2.0 10.10.2.1 0 65002 ?
PE11#show bgp vpnv4 unicast all
BGP table version is 37, local router ID is 10.10.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf A)
*> 172.16.11.0/24 0.0.0.0 0 32768 ?
*>i 172.16.21.0/24 10.10.2.1 0 100 0 65002 ?
*> 192.168.1.0 172.16.11.2 0 32768 ?
*>i 192.168.2.0 10.10.2.1 0 100 0 65002 ?
Route Distinguisher: 1:200 (default for vrf B)
*> 172.16.12.0/24 0.0.0.0 0 32768 ?
*>i 172.16.22.0/24 10.10.2.1 0 100 0 65002 ?
*> 192.168.1.0 172.16.12.2 0 32768 ?
*>i 192.168.2.0 10.10.2.1 0 100 0 65002 ?
PE11#show bgp vpnv4 unicast all labels Network Next Hop In label/Out label Route Distinguisher: 1:100 (A) 172.16.11.0/24 0.0.0.0 23/nolabel(A) 172.16.21.0/24 10.10.2.1 nolabel/23 192.168.1.0 172.16.11.2 24/nolabel 192.168.2.0 10.10.2.1 nolabel/24 Route Distinguisher: 1:200 (B) 172.16.12.0/24 0.0.0.0 25/nolabel(B) 172.16.22.0/24 10.10.2.1 nolabel/25 192.168.1.0 172.16.12.2 26/nolabel 192.168.2.0 10.10.2.1 nolabel/26
Data Plane Verification: End-to-End LSPs and VPN Label Forwarding
This traceroute from PE11 (10.10.1.1) to PE21 (10.10.2.1) verifies that an end-to-end MPLS LSP exists across the transit network. Each hop shows a transport label being swapped, confirming MPLS forwarding through the core, including the transit provider. The path demonstrates that PE11 can reach PE21’s loopback over labeled LSPs, which is essential for carrying VPNv4 traffic to remote PEs. The consistent label values across the hops indicate that the data-plane LSP mirrors the control-plane routes, providing reliable end-to-end connectivity between service providers.
PE11#traceroute 10.10.2.1 source 10.10.1.1 Type escape sequence to abort. Tracing the route to 10.10.2.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.1.1 [MPLS: Label 21 Exp 0] 8 msec 2 msec 1 msec 2 10.1.2.2 [MPLS: Label 22 Exp 0] 2 msec 2 msec 6 msec 3 10.12.1.1 [MPLS: Label 21 Exp 0] 3 msec 7 msec 3 msec 4 10.100.1.2 [MPLS: Label 21 Exp 0] 1 msec 1 msec 2 msec 5 10.12.2.2 [MPLS: Label 21 Exp 0] 5 msec 5 msec 5 msec 6 10.2.2.1 [MPLS: Label 20 Exp 0] 1 msec 6 msec 7 msec 7 10.2.1.2 2 msec 1 msec 6 msec
This traceroute from A1 to A2 (172.16.21.2) in VRF A verifies that VPN traffic is forwarded end-to-end using the MPLS LSP established between PE11 and PE21. The output shows both the transport labels assigned via BGP and the VPN label (23) for VRF A being pushed across the transit provider. Each hop swaps the transport label while preserving the VPN label, confirming that customer traffic reaches the remote PE and destination reliably over the inter-provider MPLS VPN.
A1#traceroute 172.16.21.2 Type escape sequence to abort. Tracing the route to 172.16.21.2 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.11.1 6 msec 7 msec 6 msec 2 10.1.1.1 [MPLS: Labels 21/23 Exp 0] 8 msec 7 msec 9 msec 3 10.1.2.2 [MPLS: Labels 22/23 Exp 0] 7 msec 7 msec 2 msec 4 10.12.1.1 [MPLS: Labels 21/23 Exp 0] 1 msec 2 msec 1 msec 5 10.100.1.2 [MPLS: Labels 21/23 Exp 0] 7 msec 2 msec 6 msec 6 10.12.2.2 [MPLS: Labels 21/23 Exp 0] 2 msec 7 msec 3 msec 7 10.2.2.1 [MPLS: Labels 20/23 Exp 0] 1 msec 2 msec 1 msec 8 172.16.21.1 4 msec 5 msec 6 msec 9 172.16.21.2 5 msec 7 msec 7 msec