JNCIS-SP: RSVP signaled LSP’s.

A short piece on creating RSVP signaled LSPs. I’ll create the following LSPs:
    • plain old LSP
    • LSP with a secondary LSP which is up
    • LSP requesting link-protection
    • LSP requesting node-link-protection

I will perform the configuration tasks on a lab I am currently playing with. The setup is as follows:



scenario


All routers have the basics enabled. They are running OSPF with TE extensions, there is a route-reflector cluster, they are running RSVP, etc.

I will configure and explain the different configuration statements on R24 and create an LSP to R17.


The plain old LSP.

The configuration of a single LSP is rather straightforward. Once the network is correctly configured for the label distribution protocol RSVP, you can hardly call it a task. The following configuration statement is enough to establish a unidirectional path between R24 and R17:



scenario


To verify this featureless LSP, we can use the following commands:



scenario



The LSP with an active secondary path.



Let’s enhance the LSP and provide it with a secondary LSP. The primary path should always travel via R19 and the secondary path should always travel via R25. Additionally, we want the secondary LSP to be up all the time.

We can use the following configuration to make this happen:



scenario


The keyword standby will ensure that the secondary path will be signaled and kept up at all times. The default behavior is to set up a secondary path only when it is needed.

The strict keyword indicates that the configured next-hop is mandatory. In this case, the primary path will always run via R19 and the secondary path will always run via R25. The hops after that are loose in both cases.



scenario


In the output above, you can see that both the primary and the standby LSP are up. The record route also shows that the next-hops that are applicable to both our paths differ. The primary path will go via R19 and the other path will go via R25.

When the primary path goes down, the secondary is ready to handle traffic immediately. This will save the time normally needed to signal the path.


The LSP with link-protection.

Link protection can be requested by an LSP to protect traffic sent on to the LSP from individual links failing along the path.

In the picturre below, the blue line is the LSP R24_to_R17. In anticipation to a link failure, link-protection can be used to have R19 signal a bypass LSP. When the link between R19 and R20 is configured for link-protection, the bypass LSP will go from R19 to R20 via another path.



scenario


The trick is that this LSP is precomputed, presignaled and uses the same labels. This mains that when the link between R19 and R20 failes, the bypass can be used immediately to forward traffic around the failed link.

An advantage of link-protection, over fast-reroute, is that all LSPs can make use of this bypass LSP when necessary.

In our example, we will configure link-protection in two places. The first place we will configure it is on R19 under the RSVP stanza. Through this configuration, we will make R19 provide for a bypass LSP:



scenario


The above will make it possible for R19 to look for a bypass LSP in order to protect the ge-0/0/0.3006 link.

The second place where we will configure link-protection is on R24. Here, we will configure link protection under the label-switched-path. This can be done as follows;



scenario


After this, R19 will start to look for a bypass LSP, and pre-signal this path. The LSP itself will show Link protection desired;



scenario


Let’s check R19 and have a look at the LSP and whether or not there is a bypass:



scenario


Here we see that the bypass is created and currently inactive. The label used for the bypass lsp is the same as the label used by the lsp, it’s the label to get to R20.

On R18, we can see the bypass lsp as a transit LSP:



scenario


R18 is already anticipating traffic with the 299968 label and knows how to forward it. This goes for all routers involved in establishing the link-protection.

This provides for an extremely fast restoration time when a link is down.


Node-link protection.

To provide for fast restoration times when an entire node goes down, the feature node-protection is needed. Node protection also works by setting up a bypass LSP. Only this time, the bypass LSP will bypass an entire node instead of a link as we saw with link-protection previously.

The configuration is rather straightforward:



scenario


After this configuration, we can see that the LSP now requests both node and link protection:



scenario


This time, the bypass will not be setup via R18, to circumvent the link between R19 and R20. This time, the bypass LSP will be setup around R20, via R21:



scenario


We can see the bypass LSP by logging on to R21 and performing:



scenario


Anyway, that is the basic configuration.


10-9-2014