JNCIS-SP: MPLS part1.

Since MPLS is one of my favorite subjects, I'll do a more extensive lab on this subject. I'll mix some theory as I'll gradually expand the lab until most of the topics from JNCIS-SP are covered.



MPLS: Multiprotocol Label Switching.

In a 'normal' IP network, an IP packet is processed at each hop in the network. Every router along the path performs a lookup in the routing table and determines the next-hop based on the destination IP address of the packet like so;



scenario


With MPLS, labels are used to forward traffic through the network. A packet is assigned to a FEC by an ingress LSR. The ingress LSR will prepend an MPLS label to the packet and it will switch it to the next router. The next router will only look at the label and 'switch' the traffic instead of performing a routing lookup in its IP routing table. Finally, at the end of the LSP, the LSR performs a POP operation and sends the packet onto the LAN;



scenario


Some basic terminology.

MPLS comes with a lot of terminology. Before we configure the first few routers, let's go through some definitions:



    • LSR: Label Switch Routers. A router with the ability to forward packets based on MPLS labels.

    • LSP: Label Switched Path. A unidirectional path from ingress to egress LSR where traffic is switched based on labels.

    • Label: an MPLS label that consists of the following fields:

        Label value: a locally significant value that changes from LSR to LSR as the packet traverses the LSP.
        EXP: experimental bit, used for class of service.
        S: bottom of stack bit, indicates whether the MPLS packet has more than 1 label. If the value is 1, it's the last label.
        TTL: the time-to-live. The packet is discarded on 0.



scenario




    • Label operations: MPLS routers can perform a number of actions on labeled packets, some of which are;

        Push: push a label onto a packet. This label places the packet in a FEC that determines the rest of the traffic flow through the MPLS tunnel.
        Swap: LSRs along the LSP will replace the top label in the MPLS label stack with their label.
        Pop: remove the top label of the MPLS label stack and forward the packet with or without a label.


    • FEC: Forwarding Equivalence Class. Used to describe a set of packets with similar or identical treatment. The FEC is determined by the ingress LSR.

The start of the lab.

We'll start out with three routers and perform three initial tasks in this phase:

  1. configure all the routers as OSPF routers in area 0.0.0.0
  2. enable MPLS and RSVP on the interfaces between the router
  3. configure an LSP from R6 to R10 and vice versa


scenario


1: OSPF.

In order to build an MPLS network, we are going to need an IGP. I'll explain this later on. The OSPF configuration is going to be very straightforward since the lab is not about OSPF. On the above routers, I will run OSPF and provide connectivity between R6 and R10. The configuration on R7 will be as follows:



scenario


I already configured R6 and R10, so the OSPF neighbor-relationship is already established. All three routers have connectivity between their loopback addresses:



scenario


2: enable MPLS and RSVP on the interfaces between the router.

The following is configured on all three routers:



scenario


3: configure an LSP from R6 to R10 and vice versa.

LSPs are unidirectional paths. Therefore, we will need to configure LSPs on both ends of our topology. Currently, we want to use R6 and R10 as ingress LSRs. To be able to accomplish this, we will have to configure the following on R10:



scenario


And the following on R6:



scenario


Note, I also activated 'traffic-engineering' under OSPF on R7. After committing this configuration, both unidirectional LSPs are up. Now, let's take a closer look at what happened.
Let's examine how the LSP to_R10 was setup from R6.
We configured OSPF with traffic engineering, RSVP and MPLS on three routers. Nothing really happens until an actual LSP is configured. An LSP is signaled by RSVP messages. These RSVP messages are carried by OSPF's opaque LSAs in our example.
Take a look at the following picture:



scenario


After configuring the LSP to_R10, the R6 router sends out an RSVP Path message. Path messages are send by the ingress LSR with the request for an LSP. R6's Path message is directed at R10 and processed by all intermediate routers (in our case only R7).
If and when R10 is capable, it will return an RSVP Resv message. This message includes the label assignment.
Finally, R6 receives the Resv message and is able to install the RSVP LSP to R10. Let's track the labels of the LSP by examining the rsvp printouts. First, we will start on R10, the egress LSR:



scenario


R10 is the router that, after receiving the Path message, initiated the Resv message. The RSVP session is to 1.1.1.10 from 1.1.1.6. The R10 router has allocated that the upstream router should use label 3 to reach R10.
R7 receives this label and allocates a label (299808) to router R6. Also note the following in the next printout, the action that the LSR is going to take is not swap, but pop. Since R7 is the penultimate hop, the default for RSVP is that it will pop the label.



scenario


Finally, the Resv message has reached R6. Since R6 is the ingress router, it will install the rsvp signaled LSP in the inet.3 table with a push operation as follows:



scenario


The current consequences of our actions are none. We do not have anything configured that uses the LSP. But before we expand our lab and make it more interesting by utilizing the inet.3 table, let me show something that you can do with Junos.

The thing I want to show is that it is possible to configure the router to make use of the LSP for a single /32 (or a larger prefix if you want). On R10, I have an IP address configured (172.16.0.37/32) on an interface that the router is currently not being redistributed into OSPF. The means that the IP address in not in the routing table of R6 or R7.

Let's configure R6 to use the LSP for this destination IP address without altering the configuration on R10. The net result will be that R6 will push a label onto packets destined to 172.16.0.37/32 and R7 will label switch it (still performing the pop operation). We will then send a ping from R6 to that IP address and have R10 reply. Again, the address 172.16.0.37/32 is not in R7's routing table, but that does not really matter. From R6 to R10 the packet is label switched and the return packet will be routed based on the destination IP address. That destination IP address will be in R7's routing table, since the addresses of R6 are redistributed into OSPF.
First, let's configure R6 to push a label onto packets destined to 172.16.0.37/32 as follows:



scenario


To verify R6 is actually pushing a label onto the packet prior to sending it



scenario


We can see that we get a reply from R10. Although I haven't encountered a situation in which I have found this particularly useful, I was impressed with the flexibility of Junos. And mind you, this is just one of many knobs to fiddle with.



Expanding the lab, a bit.

Next thing is to expand the lab with three additional routers. This way, it will become possible to delve into some additional possibilities of the LSPs and the inet.3 table.



scenario


Since the configuration of adding all the individual routers is rather similar I'll only show R2's configuration;



scenario


Now that all new routers are running OSPF and are (probably) configured correctly for RSVP and MPLS, let's build some LSPs.
The first LSP we will build is one from R1 to R10. Or actually, we'll build one LSP with two paths. One will be the primary and the other one will be the secondary.
I configured the following:



scenario


In the configuration above, we have created an LSP towards R10. In the 'label-switched-path' stanza, we used the keywords 'primary' and 'secondary' and referred to two paths.
These two paths were defined under the 'path' stanza. The primary path must visit R2, R3 and R7. The secondary path must visit R3, R6 and R7.
Basically we will force all traffic that will use the LSP through R3 unless that router is down. Currently, in our lab, there will be only one alternate path when R3 goes down. But when there are more, you could configure the secondary path as 'loose'. That would mean 'hey RSVP, you figure it out'.
Let’s look at the LSP’s current status:



scenario


The primary path is up and the secondary path is down. This the default behavior. When the primary path fails, the secondary path will be signalled. The router will continuously try to revert back to the primary path. The default revert timer (which is configurable) for this is 60 seconds.
This behavior can easily be altered through configuration. By configuring ‘standby’ under the mpls hierarchy, Junos will signal the secondary LSP before the primary is broken.
This saves time when the primary does break. The disadvantage is of course that it takes up extra resources.
Anyway, only the following is needed to have Junos signal the secondary LSP preemptively:



scenario


The following will be the result:



scenario


Let's configure an LSP from R10 to R1 and do something else, use FastReroute. FastReroute is a feature configured under the LSP on a node. It will request the transit nodes to precompute and pre-establish detours (when possible) to minimize downtime when a node or link fails.
The picture below is what will happen when we configure FastReroute:



scenario


When we configure LSP R10_to_R1, an RSVP signaled LSP will be established between R10 and R1. Transit LSRs will attempt to establish detours, if and when possible. In our lab, there is only 1 detour possible.
When the LSP between R10 and R1 comes up, it will run through R6. Only R7 will have a detour. R10 will 'desire' FastReroute and R7 will precompute and establish the detour through R3. This minimizes the effect of an interruption between R7-R6-R2.
To configure FastReroute, perform the following:



scenario


In the output of the LSP on the ingress router, you can see that FastReroute is desired;



scenario


On R7, the following will be displayed;



scenario


Through the use of Fast Reroute, you are creating a One-to-One backup. The 'fast-reroute' statement is configured in the label-switched-path' hierarchy for 1 LSP only.
Beside Fast Reroute (and the previously discussed secondary path) there another method to protect the network against LSP failures, this is the facility backup defined in RFC 4090.
Where Fast Reroute creates a detour to protect 1 LSP, the facility backup creates a bypass LSP that can be shared by multiple LSPs.
In Junos, the facility backup methods are link-protection and node-link protection. Let's look at link-protection.
We'll configure an LSP from R1 towards R7, run the primary path across R3 and request link-protection for the LSP. On R2 we'll activate the link-protection and use several commands to verify our configuration.
First the LSP:



scenario


The configuration of the LSP can be done as follows:



scenario


Given our topology, R2 would be suitable to grant the link-protection. If we look at the LSP right now, we can see that link-protection is desired and down;



scenario


To be able to provide for link-protection, RSVP has to be able to signal the bypass. This has to be configured under the [ protocols rsvp interface ] menu like this;



scenario


That was the link towards R3. Now, when we look at a snippet of the 'show mpls lsp extensive' command on the transit router, we can see that the link-protection is up;



scenario


Note that the bypass LSP the RSVP feature created will not be shown in the 'show mpls' output. The bypass LSP created would be the following (bypass is in green):



scenario


Before moving on, let's have a final look at the RSVP messages.



scenario


RSVP has two primary message types:

Path: to request that the LSP is created. The path message is sent from the host that wants to setup the LSP. The message traverses along the hosts of the soon-to-be LSP and stores path state in each node along the path. The most important thing stored is the IP address of the previous node. Resv: to reserve resources for the LSP, the Resv message is sent from the receiver to the sender host along the reverse data path.
To signal errors, RSVP uses the following messages;

Path Err: error messages sent to upstream sender. The router sends a unicast PathErr message to the sender that issued the path message. Resv Err: an error messages sent downstream when a reservation request fails.
Two more to remove path or reservation state;



scenario


PathTear: sent to tear down path states and dependent reservation states in any router along the path. The message is sent downstream from its point of initiation. ResvTear: deletes the state of the reservation. The message travels upstream from its point of initiation.

Let's redesign the lab to the following layout:



scenario


We'll build a miniature ISP core network with RSVP-signaled LSPs. There will be 3 PE routers that will use the network to provide a layer 3 VPN for three locations belonging to a single customer.

The 'physical' layout of the lab:



scenario


Let’s proceed with the following;

       • Activate LDP on the P and PE routers (OSPF is already running) and examine its operation
       • Create a routing-instance for the customer
       • Configure BGP neighbor relationships between the PE routers
       • Examine the L3-VPN

LDP:

LDP stands for Label Distribution Protocol. It can be used with or instead of RSVP. LDP is quite different from RSVP. For instance, whereas RSVP will use the TE extensions to provide for traffic engineering, LDP does not. LDP follows the IGP best path and cannot be directed to follow or avoid certain links. Another difference is that LDP will distribute labels and provide LSPs immediately. This means that, contrary to RSVP, there are routes installed into the inet.3 table as soon as there are LDP routers exchanging labels. LSPs needn't be manually defined.
Let's look at an example. I have activated LDP on all the ISP routers except for R7. To enable LDP on R7, perform the following;



scenario


Right after commiting, R7 will form an LDP neighbor relationship with the adjacent routers (since I already activate LDP on those routers). This happened due to the Hello-based neighbor discovery. The discovery process can be by sending a hello message to 224.0.0.2 or to a specified address (extended discovery). In both cases, UDP port 646 is used. If a neighbor relationship is formed, the node with the highest IP address will be the active node. The active node will initiate a TCP session with the neighbor. Over this session, the routers will exchange information (labels, modes, etc.) and keepalives.



scenario


The overview shows us several interesting things;
     •router-id is the loopback interface when not manually configured
     • LDP route preference is 9 (RSVP is 7)
     • default Juniper protocol modes;
       — Distribution: unsolicited. The label will be distributed to the neighbors without the neighbors having to request it.
       — Retention: liberal. All received labels are stored. Whether the label is used for forwarding is irrelevant.
       — Control: ordered. Junos initiates transmission of a label mapping for a FEC for which it has already received a label mapping (labels received from other neighbors) and it's loopback interface (exact details in RFC5036 / 2.6.1.2)
     • and then a slew of timers


Routing-instance:

A routing-instance is a collection of routing tables, interfaces and routing protocol parameters. There are several types of routing-instances, but for the creation of a L3-VPN, we will use the routing-instance type 'vrf', VPN routing and forwarding.
The other basic configuration requirements are placing an interface into the routing-instance, assigning a route-distinguisher and a route-target. I'll cover the route-distinguisher and route-target when we build the BGP neighbor relationships between the PEs.
Anyway, the basic configuration on R6 would look as follows:



scenario


This configuration will create a 'CUSTOMER-1.inet' routing-table. This routing table will be populated with the ge-1/1/3.55 interface IP address and the static route. I configured a default route to R6 from R9, so I should be able to ping R9's loopback;



scenario


I configured the exact same vrf on R7 and R2. Currently, this VPN is rather useless as it does not connect together R1, R9 and R10.
To provide for connectivity between these three routers across the MPLS network, we will need to configure some BGP neighbor relationships between the PEs.

BGP neighbor relationships:

During the configuration of the routing-instance, a route-distinguisher (RD) and a route-target (RT) were specified. Both of these are required and will be used by BGP.
To provide for connectivity between the different CUST routes, we will use BGP. BGP will distribute the static routes and the IP addresses configured on the interfaces placed in the routing-table. To be able to do this, BGP carries the routing information in the so called BGP extended community attribute RT. In short, in our case the RT is used to distinguish in which routing table the carried routing information is supposed to be placed.
The RD is used to disambiguate the IPv4 addresses. For instance, suppose there is a CUST-1 table and a CUST-2 table. Both customers want to use 192.168.1.0/24. This is possible with the RD. BGP will not exchange the 192.168.1.0/4 IPv4 prefix range, it will exchange VPN-IPv4 routes. The VPN-IPv4 route, is an IPv4 address with an 8-byte RD prepended to it.



scenario


Apart from the RT and RD, BGP will also signal an MPLS label that will be specific for the VPN. To forward VPN traffic between two PEs, the routers will use two labels. The first label (outer label) will identify what LSP to use. The second label (inner label) will identify the outgoing interface from the egress PE to the customer router.
This way, intermediate routers do not need to be aware of all the routes to all the customer VPNs. They simply switch traffic based on the outer label. It would look something like this;



scenario


So in short, BGP is used to distribute the VPN IPv4 prefixes with attached RT and MPLS labels between the PE routers. Let's configure this on R6 our example and see what happens;



scenario


After the sessions reach the state established, let's look at what is exchange between R6 and R7:



scenario


These two commands show that the necessary information was exchanged between the two routers, the RD, RT and VPN-label.
Let's place the received BGP information right above the information installed into the forwarding table for a clear overview;



scenario


Anyway,
entire books were written on the subject, but I suppose this covers at least some of the JNCIS-SP exam.
I'll do a part 2 on some other MPLS applications like VPLS.


24-8-2014