This is the 5th and final post of my MPLS series. You can find all posts under mpls-tutorial tag. So far I have run all SRX devices in packet mode which means we weren’t able to use service features of SRX firewall. With this new config, we can also inspect the traffic. You can find the juniper document which describes this setup also in here I am just taking the flow section of this document and try to explain it the way I comprehend it. I have also modified my topology to make things simpler.
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.
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.
This is the 3rd post of my MPLS/RSVP series. In the first and second, I set up an MPLS cloud with some sort of redundancy. In this post, I will enable traffic engineering support on OSPF in order to use CSPF and fast reroute feature. To explain fast reroute I need the topology again;
In a standard MPLS setup without fast reroute, if you have an LSP from J35 to J40 (Path: J34->J30->J29) and link between J30 and J29 breaks, it will take time for PATH error message to be received by J35 ingress router. However, if you enable fast reroute every router along the path will have alternate PATH available in case its link breaks and detours very quickly and will keep forwarding the traffic till the new LSP is established by the ingress router.
Please note that this is a temporary workaround to keep the traffic flowing without any disruption. Now it is time to get into the CLI to see how this works;
We must enable traffic engineering on OSPF and CSPF on MPLS. Otherwise fastreroute doesn’t work. This is what I have seen at least. In addition to this, my OSPF setup is multiarea for which I have to enable expand-loose-hop option in every MPLS router. According to the description from Juniper page “ it allows an LSP to traverse multiple OSPF areas within a service provider’s network.” Also according to juniper docs, if you configure an interarea LSP, you must set inter-domain option.
In my previous post MPLS/RSVP configuration & troubleshooting I have configured two LSPs between two MPLS routers. Now I will continue where I left off. Just one thing I must inform you that MPLS labels in the previous post won’t match this post as I restarted my routers. We will again use the same topology;
Previously we had two LSPs but didn’t know what to do with them. Now we will see how we can make use of them. When we create the LSP, one new routing table inet.3 will be populated.
root@j35> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.8/32 *[RSVP/7/1] 00:29:24, metric 40
> to 188.8.131.52 via ge-0/0/1.0, label-switched-path j35-to-j40
inet.3 is the MPLS routing table. Once an LSP is established, you can find it here. You can see this table in an Ingress MPLS router but not in transit one in which you can see mpls.0 switching table populated.
BGP has very close connection with this table. For example, the network 184.108.40.206/24 has been discovered via IBGP from J40 to J35. This means protocol next hop is 10.1.1.8 address. BGP first look in the inet.3 table and if it finds 10.1.1.8 there, it will install the physical next hop in inet.0
I would like to show how I configured my MPLS cloud with RSVP signaling in this post. This is the first post of my RSVP,MPLS/VPNs series. I will use the topology below throughout my posts. In a real world MPLS core, things may be different but this is just a lab.
I have a provider MPLS core (AS8500) and several customers A,B,C,D
with different AS numbers. Addressing is as it is depicted in the picture.
RSVP as the label distribution protocol dynamically establishes Label Switching Paths (LSP) and it is fundamental to MPLS which uses this information to create its forwarding tables. Here I use OSPF to discover the paths, which means your network must already have a working OSPF for RSVP to function properly.
Below are the steps I have taken to configure this label distribution protocol plus MPLS on top of it. I am also sharing the problems I have experienced on the way. I still lack tons of things on these protocols and the more I learn the more I see how it is immense and not easy to digest.
We have to start somewhere, let’s begin with RSVP.