A lot of people seem to get terms wrong and assume that MPLS means L3VPN MPLS. But L3VPN is just a type of MPLS application. As is EoMPLS/ATOM/VLL/VPLS. Regular MPLS is simply MPLS. No MP-BGP involved.
In fact it’s perfectly possible to run L3VPN over a non-MPLS core. You can just run the PE to PE links over GRE. The PE routers still run MPLS, but the P routers don’t. Let’s have a look at this using the following topology:
For whatever reason R1 and R2 do not run MPLS. No LDP, RSVP, nothing. All they are running is OSPF. This is the extent of R1’s config:
interface Loopback0 ip address 220.127.116.11 255.255.255.255 ip ospf 1 area 0 ! interface GigabitEthernet1/0 ip address 10.0.13.1 255.255.255.0 ip ospf 1 area 0 ! interface GigabitEthernet2/0 ip address 10.0.12.1 255.255.255.0 ip ospf 1 area 0
R5 and R6 are our CPEs both running OSPF. Each has a loopback that they are advertising into OSPF. Nothing special so I’m not even going to show the config.
As always with a lot of MPLS application work, 95% of the work is done by the PE kit. Let’s start with R3:
ip vrf CUS1 rd 18.104.22.168:100 route-target export 200:100 route-target import 200:100 ! interface Loopback0 ip address 22.214.171.124 255.255.255.255 ip ospf 1 area 0 ! interface GigabitEthernet1/0 ip vrf forwarding CUS1 ip address 10.0.35.3 255.255.255.0 ip ospf 2 area 0 ! interface GigabitEthernet2/0 ip address 10.0.13.3 255.255.255.0 ip ospf 1 area 0 ! router ospf 2 vrf CUS1 redistribute bgp 200 subnets ! router bgp 200 no bgp default ipv4-unicast neighbor 126.96.36.199 remote-as 200 neighbor 188.8.131.52 update-source Loopback0 ! address-family vpnv4 neighbor 184.108.40.206 activate neighbor 220.127.116.11 send-community extended exit-address-family ! address-family ipv4 vrf CUS1 no synchronization redistribute ospf 2 vrf CUS1 exit-address-family
You’ll notice that there is no LDP or RSVP running on this box either. However at this point even though route-advertisements are working, traffic from R5 to R6 will not actually work. When the traffic hit’s R1 it’ll just drop it.
What we need is a GRE tunnel from R3 to R4. We then run LDP through this tunnel and ensure that the routers use the tunnel as a next-hop to get to each others loopback. Note that we aren’t using LDP to advertise labels here. We are simply enabling it as the tunnel interface will be receiving the bottom of stack VPN label and will error if it receives this on a non-MPLs interface
interface Tunnel34 ip unnumbered Loopback0 mpls ip tunnel source GigabitEthernet2/0 tunnel destination 10.0.24.4 ! ip route 18.104.22.168 255.255.255.255 Tunnel34
So, does traffic flow?
R5#ping 22.214.171.124 source 126.96.36.199 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 108/121/144 ms
Let’s take a look at traceroute:
R5#traceroute 220.127.116.11 Type escape sequence to abort. Tracing the route to 18.104.22.168 1 10.0.35.3 72 msec 84 msec 44 msec 2 10.0.46.4 [MPLS: Label 17 Exp 0] 104 msec 152 msec 108 msec 3 10.0.46.6 120 msec * 144 msec
You do see an MPLS hop, but that’s simple the VPN label. There is no transport label used and MPLS is not enabled anywhere in the core.
Let’s take a deeper dive into each hop to see exactly what packets are sent out each interface.
R5 sends ping to 22.214.171.124
R3 has imposed both an MPLS VPN label on, as well as a GRE header. Notice I now have 2 IP headers, the GRE header, and the MPLS VPN label. The MPLS label of 17 will remain unchanged end to end, as it’s just a VPN label, not a transport label.
Again exactly the same. Notice that if I was using MPLS as the transport, the outer label would’ve been popped now for PHP. But as mentioned before, this is a VPN label so goes through unchanged.