Basic TE Tunnel w/ OSPF
Load mpls.te.init.with.ospf.cfg or mpls.te.init.with.ospf.and.rsvp.cfg (to skip enabling RSVP-TE)
The basic IP addresses, L3VPN between XRv14 and XRv13, and OSPF has been pre-configured.
Currently traffic between XRv14 and XRv13 is not working because LDP is not running in the core. Configure an RSVP tunnel on the PEs, CSR8 and XRv11, that takes the following path (both forward and reverse):
CSR8
CSR9
CSR2
CSR10
XRv11
Answer
First we must enable RSVP and MPLS-TE on all routers and all interfaces. CSR1 and XRv11 are given as an example. If mpls.te.init.with.ospf.and.rsvp.cfg was loaded, this step is skipped.
Next we enable MPLS-TE under the IGP, which is OSPF in our case
Additionally, on IOS-XR, we must enable LDP in order for the LFIB to function. We don’t need to actually enable LDP on any interfaces.
Now we are ready to create the TE tunnel interfaces on each PE. Create an explict-path that defines the static path we want the LSP to take:
Verification
We can quickly verify that traffic between the two CEs (XRv13 and XRv14) is taking the correct path in the core. (We did not disable TTL propagation in the core).
This tells us the tunnel is working, but we can also verify the tunnel is up and signaled.
We can also see the ERO on the path for which CSR8 is the headend:
CSR8 is acting as the tailend for the second tunnel which is why it has no ERO
Any transit router in the path has state for these two tunnels as well:
We use the same command on XRv to verify the tunnels:
We can also filter this by role on both XE and XR, for example:
Theory
MPLS-TE allows you to preform source routing - the ingress LSR controls the path traffic will take. MPLS-TE allows for path calculation using many more constraints that just the IGP metric. You can use link affinity, available bandwidth, or TE metric. MPLS-TE also allows you to use the fast reroute feature, but we will hold off on exploring this until later.
MPLS-TE uses the following concepts:
A TED (TE database) to store these new metrics, and a way to feed it (using the IGP)
A protocol for signaling the LSP, keeping the state refreshed, advertising the label hop-by-hop, and reserving bandwidth in the control plane (RSVP)
A way to forward traffic over the LSP (autoroute announce or forwarding adjacency)
To start, we enable MPLS TE globally (mpls traffic-eng tunnels on IOS-XE) and enable MPLS-TE per interface (mpls traffic-eng tunnels under the interface on IOS-XE, and mpls traffic-eng int X on IOS-XR). Next we also need to enable RSVP on all interfaces, as RSVP is the signaling protocol used for MPLS-TE. This is done on IOS-XE with ip rsvp bandwidth [ bw ] and on IOS-XR under rsvp int X bandwidth [ bw ]. By default, if the bw is not specified, it defaults to 75%. (In this case, you just use the bandwidth statement with no specific bandwidth). Note that if you do not wish to allocate bandwidth on each interface, then you don’t need any rsvp commands on IOS-XE nor IOS-XR. RSVP is automatically activated when activating mpls traffic-eng tunnels under an interface in IOS-XE, and when activating an interface under mpls traffic-eng on IOS-XR.
IGP
Next, we need to enable MPLS-TE on the IGP, because it will be used to carry the link attribute information. Specifically it will carry the TE metric, the link affinity, and the available and reserved bandwidth for each bandwidth priority level (0-7).
OSPF and ISIS are the only supported IGPs for MPLS-TE, because MPLS-TE can only work with a link-state protocol. This is because the ingress router is preforming source routing - it is independently calculating the entire route from itself (the headend) to the tailend. This means the headend needs to know the entire database of links and their attributes, hence the need for a link-state protocol.
We will look at ISIS in the next lab. In this lab we enable MPLS-TE for OSPF using two commands:
The router-id must be specified to give the router its identifier in the TED graph. This is not automatically generated as the loopback, so if we don’t specify this, the node won’t have a TE RID and can’t originate the TE LSAs.
OSPF was extended with support for Opaque LSAs which provide a general mechanism to extend OSPF. Opaque means that OSPF itself is not using the information for SPF, it is just carrying the information for some other application (in this case MPLS-TE). LSA 9 is link-local scope, LSA 10 is area scope, and LSA 11 is AS-wide scope. MPLS-TE only uses LSA 10 because the link-state graph is only area-wide. MPLS-TE support for inter-area TE does not actually use LSA 11, interestingly enough. (We will see inter-area TE in a future lab).
The Opaque LSAs carry TLVs which makes OSPF easier to extend, similar to ISIS. Opaque LSAs use the same 32 bit Link ID as any other LSA, but the first 8 bits are the Opaque type, and the last 24 bits are the instance number (ID). Type 1 is the TE LSA type for Opaque LSAs, so all of our LSAs will start with 1.x.x.x
Each router will originate one LSA with ID 0 for itself, as a sort of “Opaque router LSA.” This contains its TE RID. Additionally, one LSA is originated for each link, containing the attributes of the link. For example:
The ID is the interface’s ifIndex value. So above, the interface must have the ifIndex value of 8. The Link ID in the above LSA indicates the neighbor on the other end of the link. Also note that bandwidth is expressed in bytes per sec, not bits per sec, which can throw you off.
Once all Opaque LSAs have been flooded, we can see the TED on any router in the area using show mpls traffic-eng topology.
When reservable bandwidth values change “signficantly enough” they are flooded using regular LSA flooding techniques. You don’t want to constantly flood LSAs for very small changes. So by default, LSA flooding is triggered when bandwidth crosses certain percentage thresholds: 15, 30, 45, 60, 75, 80, 85, etc…
The TE Tunnel and CSPF
Now that the IGP has flooded the TE information, each router has a complete TED. This allows any router to compute an LSP that meets a wide variety of constraints, such as:
Bandwidth required
Link affinity
Setup/hold priority
Use TE metric (this is the default setting, as opposed to using IGP metric)
Note that the tunnel destination is the TE RID of the tailend router, which is not necessarily a reachable IP address, but usually the lo0 address.
The TE tunnel path-option controls how the tunnel is setup. In this lab we used an explicit path-option to 100% dictate the path the tunnel will go. We could add a second path-option as dynamic which means “if the first path-option fails, then setup the tunnel using TE metric.”
We can also use explicit paths that exclude nodes/links or loosely include a single node/link, etc.
When you give the TE tunnel a path option, it tries to run CSPF using the constaints you’ve given it. CSPF runs against the TED and prunes away links that don’t meet the constaints. If a path cannot be calculated, the next path-option is tried. If no path-options can find a path, the tunnel is not signaled at all. But if a path is calculated, it is translated into an ERO (explicit route object) and signaled via RSVP.
RSVP-TE
Now that a path has been calculated, we need a way to signal the path and keep it refreshed, as well as signal the labels hop-by-hop. Every router along the path also needs to reserve the bandwidth requested by the LSP (if there is any bandwidth requirement on the tunnel). RSVP was extended to do exactly this for MPLS-TE, and is called RSVP-TE.
RSVP uses a PATH message from headend→tailend, and a RESV message from tailend→headend.
The PATH message, as it leaves the headend, has the full path the LSP should take listed in the ERO. The ERO is an ordered list of every hop the LSP will take. At each hop, the router removes its own IP address from the ERO. The length of the ERO gets shorter hop by hop. There is also an optional record route object, in which each router places its IP address. This object gets longer hop by hop.
Here is the PATH as it leaves CSR8 (the headend):
The time value is the refresh rate (30 seconds)
The Label request means that a label value is requested. The label value will be signaled “on the way back” in the RESV message
The Sender TSPEC contains the bandwidth requirement (although there is no bandwidth required for this particular TE tunnel)
If we look at the PATH as it leaves CSR9, we can see that CSR9 has removed itself from the ERO, and added itself to the Record Route:
When the tailend receives the PATH message, it sees that it is the tailend (destination) from the Session object. It then sends a RESV message in the reverse direction. Each router knows the previous hop the PATH message took by storing the “HOP” value on the PATH message in memory. (Notice this is separate from the ERO - two fields above the ERO in the pcap above). This is recorded on each router and associated with the path’s session ID. As the router receives a RESV message, it looks up the previous hop known from the PATH message in order to send it in the exact reverse direction. The RESV message contains the label at each hop.
Here is the RESV message received at CSR8:
Style: Shared Explicit means that make-before-break is implemented. If a reroute occurs, bandwidth would otherwise be accounted for twice in the time during which both the old and new paths are setup. With SE, the double booking of bandwidth is prevented on the same link on all routers in the path of the LSP. (Routers recognize that the new TE tunnel has the same session ID as the old one, so they know not to reserve bandwidth for this new TE tunnel if it crosses the same interface.)
By default, the tailend advertises implicit null to its upstream hop. You can optionally change this to explicit null, but IOS-XE still interprets this as implicit null, and preforms PHP. You must change this behaviour using mpls traffic-eng signalling interpret explicit-null verbatim on the penultimate hop router if you want the router to honor an explicit null.
Forwarding traffic onto the TE tunnel
The tunnel is now setup but it is not carrying traffic yet. We have a few options for directing traffic into the tunnel:
statically route the tailend via the tunnel interface
autoroute destination, which puts a static route to the destination via the tunnel in the RIB automatically
autoroute announce, which lets the local IGP use the tunnel interface for SPF calculation. This could use the tunnel for destinations one or more hops beyond the tunnel destination.
forwarding adjacency, which advertises the tunnel as an adjacency into the IGP, so other routers in the area can use the tunnel as part of their own SPF.
class-based tunnel selection, which directs traffic into a tunnel based on the EXP marking
In this lab we simply used autoroute annouce, which is a frequently used option.
Last updated
