MPLS/RSVP and BGP L3VPN #4

This post is the 4th post of my MPLS series. You can find the first three here: #1, #2 , #3
In an MPLS network, PE routers keep the site specific VPN routes inside VRF (Virtual Routing and Forwarding) tables and send the routes that they learned from CE routers to remote PE routers by using MP-BGP (Multiprotocol BGP). LSPs we have configured so far will be used to send our L3VPN traffic.
One of the greatest things that VRF along with MP-BGP is that in your PE router you can keep the same network addresses in different sites and completely isolated from each other.

mpls_ospf_rsvp

I will setup a BGP-L3VPN between CustC (10.10.10.0/24) and CustA (10.20.20.0/24)

I can start configuring VRF tables on both sides. VRF is a simple routing instance in a junos box but its instance type is vrf. For simplicity I won’t configure BGP between CE and PE routers but you can also do that.

Lets configure the first VRF instance on J40 router for CustC

CustC VRF Configuration

Some configuration items on this VRF instance require some explanation;

interface ge-0/0/2.0: This is the gigabit interface which provides connection to this multiaccess network CustC is also part of it.

route-distinguisher: This is used to identify the routes sent by this particular VPN and each instance must have its own

unique route-distinguisher. Note that it is unique. It must be different in all instances in the PE router.

vrf-target: With import statement any route received with this target (i.e exported from other PE router) will be put into CustC.inet.0 table. Export statement does the reverse. It advertises all routes in CustC.inet.0 table with 8000:100 tag. If we speak specifically for this CustC and CustA L3VPN connection, route targets must be the same in both sides.

vrf-table-label: You can visit the address here for this statement as well. As I have a multiaccess network, I need to enable this statement without which I am unable to send my VRF routes.

CustA VRF Configuration

Note: You can note the difference in vrf-target single line statement. For this setup, it also works.

We configured VRFs but we haven’t shared these routes between PE routers J35 and J40. For this, we must modify BGP configuration at both side and enable family inet and inet-vpn.

At both sides, required configuration is done. Now lets see how our routing tables look like.

J40

If you take a look at this VPN-IPV4 route (2001:10:12.1.1.0/24), you can see that is prefixed by “2001:20” which is the route-distinguisher we configured on J35.

J35

Routing table bgp.l3vpn.0 contains all VPN routers received from other PE routers and based on the vrf-target, route is installed into the respective VRF. Let’s check how routes are installed in VRF instances.

VRF route tables

As you can see, network 12.1.1.0/24 from J35 is now available in J40’s VRF table as a BGP route and 98.1.1.0/24 from J40 is now available in J35’s VRF table.

In the beginning of the post I mentioned that CustC has 10.10.10.0/24) and CustA has 10.20.20.0/24 networks. Let’s distribute these as well by static routes:

As you can see again, new static routes are sent via MP-BGP and installed on VRF tables. By using this technique, you can have lots of customers who are using the same network without having any duplicate network address issue.

Last but not least I would like to show how an MPLS frame looks like on the way and just before the PE router.

I did a test by sending a single PING from J36 router towards 10.10.10.1 address. It is tunneled across the L3VPN that I configured. What I am interested is how the frame looks like on two links.

  • Between J33-J32
  • After J32
  • Between J33-J32
    label_stack_mpls

    If you look carefully at this frame which I captured before it arrives at J32, you see that it has dual label. Outer label is 299762 as expected from the output from RSVP session command below and the inner label is 17. We will see why it is 17 below;

    After J32

    l3vpn_popped_label

    This frame has been captured just before it arrives at J40. J32 removed the outer label as it does PHP. If you take a look at mpls table of J40, you can see that it sends any MPLS frame having 17 label to vpn-CustC.inet.0 table after popping it. If you asked me how does J35 knows this label 17, I can say that they share this label during MP-BGP route exchange.

    I hope this post was useful to explain BGP L3VPN in junos. I have tried to be as simple as possible for my future readings as well:)

    If I can I would like to add one more post in which I can use flow mode SRX with MPLS but it is a bit more complex setup than this one. I will see when I can get round to it.

    Stay tuned!

    2 thoughts on “MPLS/RSVP and BGP L3VPN #4

    You have a feedback?