# 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)

```
#IOS-XE
config replace flash:mpls.te.init.with.ospf.cfg
! or
config replace flash:mpls.te.init.with.ospf.and.rsvp.cfg

#IOS-XR
configure
load bootflash:mpls.te.init.with.ospf.cfg
! or
load bootflash:mpls.te.init.with.ospf.and.rsvp.cfg
commit replace
y
```



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 <a href="#id-97be8141-e3aa-4486-9d6a-ceb63bac10a8" id="id-97be8141-e3aa-4486-9d6a-ceb63bac10a8"></a>

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.

```
#CSR1
mpls traffic-eng tunnels
!
int GigabitEthernet2.513
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000
int GigabitEthernet2.514
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000
int GigabitEthernet2.516
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000
int GigabitEthernet2.517
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000
int GigabitEthernet2.518
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000
int GigabitEthernet2.519
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000

#XRv11
mpls traffic-eng
 int Gi0/0/0/0.501
 int Gi0/0/0/0.512
 int Gi0/0/0/0.531
 int Gi0/0/0/0.551
!
rsvp
 int Gi0/0/0/0.501
  bandwidth 1 g
 int Gi0/0/0/0.512
  bandwidth 1 g
 int Gi0/0/0/0.531
  bandwidth 1 g
 int Gi0/0/0/0.551
  bandwidth 1 g
```



Next we enable MPLS-TE under the IGP, which is OSPF in our case

```
#CSR1
router ospf 1
 mpls traffic-eng area 0
 mpls traffic-eng router-id lo0

#XRv11
router ospf 1
 mpls traffic-eng router-id lo0
 area 0
  mpls traffic-eng
```



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.

```
#XRv11
mpls ldp
```



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:

```
#CSR8
ip explicit-path name R9_R2_R10_R11 enable
 index 1 next-address loose 9.9.9.9
 index 2 next-address loose 2.2.2.2
 index 3 next-address loose 10.10.10.10
 index 4 next-address loose 11.11.11.11
!
interface Tunnel0
 description TE Tunnel To XRv11
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 11.11.11.11
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 explicit name R9_R2_R10_R11

#XRv11
explicit-path name R10_R2_R9_R8
 index 1 next-address loose ipv4 unicast 10.10.10.10
 index 2 next-address loose ipv4 unicast 2.2.2.2
 index 3 next-address loose ipv4 unicast 9.9.9.9
 index 4 next-address loose ipv4 unicast 8.8.8.8
!
interface tunnel-te0
 ipv4 unnumbered Loopback0
 autoroute announce
 !
 destination 8.8.8.8
 path-option 1 explicit name R10_R2_R9_R8
```



## Verification <a href="#id-5ef2dbe0-21be-4fe9-a834-bb28e8d564d3" id="id-5ef2dbe0-21be-4fe9-a834-bb28e8d564d3"></a>

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).

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FDo1duclmLSQgYqNq6AE2%2Fimage.png?alt=media&#x26;token=1002154e-5f52-4c6f-98cc-ddbfda6ab490" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FppOPkot1ItmyVesR40A0%2Fimage.png?alt=media&#x26;token=8d6e2b4f-9f9b-4afe-b372-9b435098dbf4" alt=""><figcaption></figcaption></figure></div>



This tells us the tunnel is working, but we can also verify the tunnel is up and signaled.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F6PIInHGNOFFdcCDDMYDi%2Fimage.png?alt=media&#x26;token=b540ea56-8e1f-4371-ba7f-c419066eed95" alt=""><figcaption></figcaption></figure></div>



We can also see the ERO on the path for which CSR8 is the headend:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Ff1n6ZPsLZdT4eKYYY0Eu%2Fimage.png?alt=media&#x26;token=5d2dffa1-2393-4bdf-bfc3-3facbf36d882" alt=""><figcaption></figcaption></figure></div>

* 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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FHJFuJwSE24wbvnbMmFK7%2Fimage.png?alt=media&#x26;token=852f37ec-e404-4ff5-a6bd-7690b255661e" alt=""><figcaption></figcaption></figure></div>



We use the same command on XRv to verify the tunnels:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FqEvgfvm9LZAZiINcaM25%2Fimage.png?alt=media&#x26;token=8349f946-af97-4389-bd29-93b7663bbcfc" alt=""><figcaption></figcaption></figure></div>



We can also filter this by role on both XE and XR, for example:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FnkKZayLVwxHbEH4Onm03%2Fimage.png?alt=media&#x26;token=fcbad9d5-4674-4144-b6c0-e9b1c1c0a60e" alt=""><figcaption></figcaption></figure></div>



## Theory <a href="#id-09f62356-396d-4dd0-8f5c-8c9c74d44ff1" id="id-09f62356-396d-4dd0-8f5c-8c9c74d44ff1"></a>

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 <a href="#id-11fa81dc-2b27-40d4-b3cd-ff610c6e0bbd" id="id-11fa81dc-2b27-40d4-b3cd-ff610c6e0bbd"></a>

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:

```
! IOS-XE
router ospf 1
 mpls traffic-eng area 0
 mpls traffic-eng router-id lo0

! IOS-XR
router ospf 1
 mpls traffic-eng router-id lo0
 area 0
  mpls traffic-eng
```



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

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F2tbunHRooPkfEG4o9lH2%2Fimage.png?alt=media&#x26;token=b2705e3d-04fa-47da-897f-e2f9952ae6d0" alt=""><figcaption></figcaption></figure></div>



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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FNRpx4xnUn7yFv8YHAd2c%2Fimage.png?alt=media&#x26;token=8bd9898a-5a56-4e69-8cbf-e5ab86659628" alt=""><figcaption></figcaption></figure></div>



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 <a href="#id-1b22772a-fc5f-405d-b292-01e9a0f6eae1" id="id-1b22772a-fc5f-405d-b292-01e9a0f6eae1"></a>

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.”

```
interface Tunnel0
 tunnel mpls traffic-eng path-option 2 dynamic
```



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 <a href="#id-6ce7176c-e68a-4e9b-8f2e-56a0f49aa6ab" id="id-6ce7176c-e68a-4e9b-8f2e-56a0f49aa6ab"></a>

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):

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FBgNVhofCauxeNmfeETjP%2Fimage.png?alt=media&#x26;token=ec3652fd-f78b-42be-b17c-2cbc9b24fc1d" alt=""><figcaption></figcaption></figure></div>

* 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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FWHGxEYWSznt8QuiHvfcC%2Fimage.png?alt=media&#x26;token=f94cf51e-5778-4acc-a57f-3d597705f65b" alt=""><figcaption></figcaption></figure></div>



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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FkxaYOQv2MtCIwvkZ3pOi%2Fimage.png?alt=media&#x26;token=41a8ac02-96a4-4f5d-850f-fe2843f066c9" alt=""><figcaption></figcaption></figure></div>

* **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 <a href="#id-93d9cbe1-fb68-476b-992d-221fbe56e03c" id="id-93d9cbe1-fb68-476b-992d-221fbe56e03c"></a>

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.
