On PE1, we activate MPLS toward the core router that only switch label packets. We also activate OSPF on the core facing interface for the edge router to be known (routed) within the backbone. Notice that customer facing interface is added to a VRF :

On P router, we activate OSPF and MPLS on both links :

Configuration on PE2 and CE2 is not detailed because it is similar to PE1 and CE1 configuration.

Verifications :

Step 3 : configuring eBGP peering

On CE1,

On PE1,

Verifications :

Step 4 : configuring MP-BGP

On PE1, we configure iBGP peering with P2 to exchange VPNv4 routes via MP-BGP :

Similar configuration is done on PE2.

Verifications :

First issue

If we activate BGP updates debugging on CE1, we can see that CE2's routes are announced by PE1 but denied by CE1 :

This is a normal behavior : routes are rejected by CE1 because AS-PATH attribute contains CE1's AS number. This is the well known BGP loop prevention mechanism. One solution is to delete CE's AS number from the AS-PATH :

With the « as-override » command, BGP router rewrite AS-PATH attribute before sending BGP update replacing customer's AS number 64512 with it's own AS number 4200000000. This time, BGP updates are accepted by CE1 and routes are installed in CE1's RIB, notice the modified AS-PATH :

Now let's try to test connectivity between customer sites by pinging CE2's internal interface:

Ping KO, traceroute stops at PE1…

Second issue

As you noticed, we tried to set up MPLS L3VPN without configuring loopbacks on the ISP's routers. Because we don't care of redundancy in our scenario (there's only one path between edge routers), we can think that loopbacks are not required but in fact loopbacks are needed for packets can get to their destination.

The problem is that when pinging 172.16.200.254 CE2's interface from 172.16.100.254 CE1's interface, packets are leaving CE1 with only one label, the VPN label, but no IGP label on top of the label stack. When receiving these labeled packets, router P drops them, because VPN labels are irrelevant for core routers.

The reason for PE1 forwarding packets to P with no IGP label is that P distributes to its neighbors the implicit-null label for prefix 192.168.30.0/30 as it is directly connected :

Notice the outpout chain for destination 172.16.200.0/24 on PE1 :

The solution is to configure loopbacks, and use them for iBGP sessions establishment between edge routers :

Now, on PE2, next-hop for 172.16.200.0/24 is 2.2.2.2. As router P is not directly connected to 2.2.2.2/32 no implicit-null label is distributed for this prefix but label 17. Notice the output chain on PE1 :

And… it works !

Configuration file and Visio diagram

 MPLS_basic_L3VPN.zip