This time we will handle the basic traffic engineering within a MPLS network. This technique allows network admin to manipulate the traffic and fully utilize the subscribed bandwidth or circuits.
Traffic engineering within a MPLS network can be more accurate and convenience than in a typical TCP/IP network, because TE are happened at the MPLS level only, which would not affect the base of the whole network topology. If manipulate traffic at the IP level, everything running on top of IP level will be affected.
The network topology for this testing is listed below.


There are 4 different VRFs running under this test lab.
VRF: 1010020010 at R01 and 1060020010 are at R06 – Route Target: 1800:0020010
VRF: 1010020010 at R01 and 1060030010 are at R06 – Route Target: 1800:0030010

Before we apply any traffic engineering at into this network, the traffic flows from R06 to R01 is via the following path: R06 to R02 to R01. This path has the lowest OSPF metrics and becomes the best path for “Label Switching Path”.
Once we apply the following, the whole traffic from all VRF at R06 designated to R01 (10.1.0.1) will take router R05 as the second hop. In this case, we are using the loopback IP address of R05 as the next hop.


Since the traffic engineering is based on RSVP, and RSVP has lower preference than LDP, therefore it becomes a new active route at inet.3 table.

At R05, we check the mpls lsp and see what do we got.

Since R05 is the transit router, it has the LSP record of “R06-R01” at the transit table that is created at R06.
Although there is a new LSP record at R06, the traffic engineering at R06 would not affect the routes at R05. The route to 10.1.0.1 at R05 is still using LDP to drive the traffic.
At R01, the egress router of the path “R06-R01”, the command shows our TE path at the egress table. (Please ignore the MVPN records..)

The command of “show rsvp session” and “show mpls lsp” has a pretty similar output.

So far, the TE seems working. Our next section is going to manipulate the traffic to take a very long path. Indeed, taking a long path would results with high latency, however, when there are problems with the shortest path, taking the longer path allows the availability for the network to be extended.



 
Our third example, we will divide traffics into two different circuits. In the real world scenario, we will be using TE to divide traffics into multiple circuits based on different types of customers or type of traffics.
In this example we will be putting one VRFs traffic into one circuit and another VRF’s traffic into another circuit. This time, we will treat 1060020010 as our VIP client, and this customer will take a longer path that is more stable in our example.
When we are turning a particular VRF traffic to a particular circuit, we will be using the forwarding table this time. How we do is we will take the community of route target of our vip VRF and set its next hop lsp as the longer path. Our non vip VRF will take the unstable shorter path.
As listed below, we will setup 2 terms in the forwarding policy in case. Our VIP VRF route target is 1800:00200010. Our first term is for our VIP customers, and we will set a forwarding-policy as: if the RT is 1800:00200010, direct its traffic using path_R05-R3-R02-R01. The second term is to direct other VRFs’ traffic to another paths. Since there might be many VRF numbers in a PE router, and it is not that reasonable to put all the VRF RT number into a policy, the best way to handle it is to have a wildcard community to cover all VRF RT number. The wildcard can be set as 1800:*.


 
The route for different VRFs are listed below. Our VIP is taking the long path (path_R05-R03-R02-R01), and the non-VIP is taking the path-R05_R04_R01.

 
So far, these are the ways to perform TE for MPLS. We will keep yall update if there are any more ways for RSVP TE.