Juniper Logo This post is part 2, a continuation of the previous Juniper MPLS Jump Start. This post will assist you to add Layer 3 VPN / MP-BGP to MPLS networks. All available configuration files are available at github.com/networkfoo

You will learn about Layer 3 VPN / MP-BGP. You will also learn about Route Distinguishers and Route Targets in Virtual Routing & Forwarding Tables (VRF’s). In conclusion, we will look at verification of Layer 3 VPN’s.

Files for this lab can be found here, same deal as the Deploying MPLS Introduction post.

Topology

The graphic below presents the topology of the network we are building:

Topology One

To get Layer 3 VPN working, fundamentally it is all about Virtual Routing & Forwarding Route Instances.

First up, let’s add MP-BGP to all three of the Provider Edge (PE) routers that have Customer Edge (CE) routers connected on the above topology:

protocols {
    bgp {
        family inet {
            any;
         }
         family inet-vpn {
             any;
         }
    }
}

While doing this, it a good time to make sure that you have the necessary neighbor directives for all your necessary iBGP peers.

Next, we will configure VRF’s. Start with dalwhinnie, you’ll need to add:

routing-instances {
    spruce {
        instance-type vrf;
        interface em3.0;
        route-distinguisher 192.168.90.2:30;
        vrf-target target:100:300;
        vrf-table-label;
        protocols {
            bgp {
                group ce1 {
                    peer-as 65433;
                    neighbor 192.168.90.2;
                }
            }
        }
    }
    aspen {
        instance-type vrf;
        interface em4.0;
        route-distinguisher 192.168.90.6:20;
        vrf-target target:100:200;
        vrf-table-label;
        protocols {
            bgp {
                group ce2 {
                    peer-as 65432;
                    neighbor 192.168.90.6;
                }
            }
        }
    }
}

Note: For the keen observer you will have noticed I have not used the interface ge-0/0/1.800 and .801, as in the Day One book. It is just the way I did it… when venturing into uncharted territories I try to keep things as simple as possible and I thought adding IP Aliases to the mix would just confuse things.

Next, router oban also requires configuration for the peered CE4 router as well as tormore for the peered CE5 router.

Route Distinguishers

You have already done everything you need to get route-distiguishers working, with that simple line route-distinguisher 192.168.90.2:30; under the VRF configurations.

Route Targets

Here needs a little more attention to detail. We need to have our CE Routers mark the BGP routes they send with their respective VRF name and Target:

on CE4 and CE5*:

policy-options {
    policy-statement to-AS65431 {
        term match-to-AS65431 {
            from {
                route-filter 172.17.0.0/24 exact;
            }
            then {
                community add spruce;
                accept;
            }
        }
    }
    community spruce members target:100:300;
}

*of course substituting VRF name and Target where necessary.

Layer 3 VPN Verification

Hey? … Verification already? … whoa, but we have not even fired up routers CE1 & CE2, let alone configured them!!! Meh… we don’t need to. Let’s just get on with the verification and afterwards (at the very end), if you like, you can load the configuration files to do further verification.

Perusing the show route - detail output for the 172.17.0/24 route shows us that all our work has not been in vain. Exactly as in the Day One book, note the bold text:

networkfoo@dalwhinnie> show route 172.17.0.0/24 detail 

aspen.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
172.17.0.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.90.14:20
		. . . 
		. . . 
                Communities: target:100:200
                Import Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.200.86.3
                Primary Routing Table bgp.l3vpn.0

spruce.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

172.17.0.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.90.18:30
		. . . 
		. . . 
                Communities: target:100:300
                Import Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.200.86.9
                Primary Routing Table bgp.l3vpn.0
    
bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

192.168.90.14:20:172.17.0.0/24 (1 entry, 0 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.90.14:20
		. . . 
		. . . 
                Communities: target:100:200
                Import Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.200.86.3
                Secondary Tables: aspen.inet.0

192.168.90.18:30:172.17.0.0/24 (1 entry, 0 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.90.18:30
		. . . 
		. . . 
                Communities: target:100:300
                Import Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.200.86.9
                Secondary Tables: spruce.inet.0

Traceroutes & Layer 3 VPN’s

Running a traceroute to confirm our path is of little use, as the PE routers do not have a route back to the CE routers and this will show as splats in traceroute. Not exactly what we want.

networkfoo@dalwhinnie> traceroute routing-instance spruce 172.17.0.1    
traceroute to 172.17.0.1 (172.17.0.1), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  172.17.0.1 (172.17.0.1)  1.195 ms  0.792 ms  0.825 ms

We can correct this by issuing icmp-tunneling on all our MPLS routers through the network:

networkfoo@dalwhinnie# set protocols mpls icmp-tunneling 

Now we get the expected response:

networkfoo@dalwhinnie> traceroute routing-instance spruce 172.17.0.1   
traceroute to 172.17.0.1 (172.17.0.1), 30 hops max, 40 byte packets
 1  192.168.86.5 (192.168.86.5)  1.092 ms  0.624 ms  0.725 ms
     MPLS Label=300720 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=1 S=1
 2  192.168.86.9 (192.168.86.9)  0.580 ms  0.634 ms  0.661 ms
     MPLS Label=300912 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=2 S=1
 3  192.168.86.25 (192.168.86.25)  0.554 ms  0.569 ms  0.639 ms
     MPLS Label=300752 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=3 S=1
 4  172.17.0.1 (172.17.0.1)  0.888 ms  0.780 ms  0.787 ms

Depending on your circumstances you may not desire to show all this information. So we can effectively hide the MPLS path, should we want to, with the no-decrement-ttl directive. This is only necessary on the ingress router. Also, we can disable icmp-tunneling but do not need to.

networkfoo@dalwhinnie# set protocols mpls no-decrement-ttl  

Follows is our MPLS hidden traceroute:

networkfoo@dalwhinnie> traceroute routing-instance spruce 172.17.0.1    
traceroute to 172.17.0.1 (172.17.0.1), 30 hops max, 40 byte packets
 1  192.168.90.17 (192.168.90.17)  1.098 ms  0.589 ms  0.800 ms
 2  172.17.0.1 (172.17.0.1)  0.923 ms  0.791 ms  0.822 ms

Conclusion

So as you see we have proven working l3vpn connectivity. However we still have not set up CE1 & CE2 routers. I have included a ce1-l3vpn.cfg in the usual place to set up the Customer Edge router should you wish to conduct more tests.

I hope that this has helped and provided a base for further investigations.

Footnote

This was an older post ( late 2016/early 2017 ) from my networkfoo github page, where I used to mess about with Juniper equipment. I have added it here just to keep everything all in one place and also that, someone may find it interesting.