Traffic Engineering

Jan 2 2009

ISIS wide metrics

Be default ISIS caps ISIS metrics greater than 63.

To address this limitation a new IS-IS TLV was defined to overcome the limited 6-bit metric of 63. This TLV known as TLV Type 135 increased the per-link metric range from <0-63> to <1-16777214> ie the new TLV has 24-bits for the ISIS metric.

This new range can be seen under the interface config mode as shown below.

R2(config)#interface loopback 0 R2(config-if)#isis metric ? <1-16777214> Default metric

Consider the topology below.

We will attempt to increase the metric of the R2 loopback to greater than 63 with and without wide-metrics enabled.

The video below shows how to configure and verify the use of wide metrics in ISIS. Click here to download the video and watch it on your iPod.

The commands used in the video are as below:-

interface FastEthernet1/0 ip router isis !
router isis net 49.0001.0000.0000.0001.00 is-type level-2-only metric-style wide passive-interface Loopback0de>

interface Loopback0 isis metric 10000 ! interface FastEthernet1/0 ip router isis !
router isis net 49.0001.0000.0000.0002.00 is-type level-2-only metric-style wide passive-interface Loopback0

interface FastEthernet1/0 ip router isis ! interface FastEthernet1/1 ip router isis !
router isis net 49.0001.0000.0000.0003.00 is-type level-2-only metric-style wide passive-interface Loopback0 !

To verify the wide metric on R1 use the command below.

R1#show isis database R2.00-00 detail

IS-IS Level-2 LSP R2.00-00 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL R2.00-00 0x0000000E 0x1A31 428 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: R2 IP Address: 2.2.2.2 Metric: 10 IS-Extended R3.02 Metric: 10000 IP 2.2.2.2/32 Metric: 10 IP 10.0.0.4/30

By zismail • CCIE SP, iPod, IS-IS, Traffic Engineering • 0 • Tags: CCIE SP, IS-IS, TE, Traffic Engineering

Dec 2 2008

Traffic Engineering – Fast Reroute

Fast reroute (FRR) is one of the main drivers for implementing Traffic Engineering. Fast Reroute uses the concept of a backup tunnel. When the path used by the primary tunnel is detected as down, traffic is dynamically switched over to the backup tunnel.

Fast reroute provides two types of protection.

1-Link Protection

2-Node Protection

Lets examine the topology below.

Link Protection

Lets suppose the primary path for a tunnel whose headend is at PE1 and tailend is at PE2, that the primary path is via PE3.

If the link between PE1 and PE3 fails then fast reroute link protection reroutes the traffic using the following path.

PE1–>P1–>PE3–>PE2

As you can see the reroute mechanism has rereouted around the failed link. These type of FRR backup tunnel are known as Next-Hop back tunnels(NHOP).

Node Protection

Lets suppose the primary path for a tunnel whose headend is at PE1 and tailend is at PE2, that the primary path is via PE3 and not P1.

If the node PE3 fails then fast reroute link protection reroutes the traffic using the following path.

PE1–>P1–>PE2

As you can see the reroute mechanism has rereouted around the failed node. These type of FRR backup tunnels are known as Next-Next Hop back tunnels(NNHOP).

Configuring FRR

The configuration of Traffic engineering has evolved over the years, In the beginning both the primary and backup tunnel had to be configured manually. Then the backup tunnel evolved to be dynamic configuration and now even the primary tunnel is almost fully automated.

Below we will show an how to configure an autotunnel Primary and Backup

To configure the autotunnel on PE1 simply enter the following command.

PE1(config)#mpls traffic-eng auto-tunnel primary onehop

You will then see a primary tunnel comeup for each directly connected traffic engineering enabled neighbor.

00:06:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65336, changed state to up 00:06:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65337, changed state to up

PE1#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1_t65336 4.4.4.4 - Fa2/0 up/up PE1_t65337 2.2.2.2 - Se1/1.1 up/up Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails

To configure the backup tunnels use the following command:

PE1(config)#mpls traffic-eng auto-tunnel backup

Shortly after entering the above command you will see 2 backup tunnels come up.

PE1(config)# 00:03:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65436, changed state to up 00:03:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65437, changed state to up

The command below shows that tunnels 65436 and 65437 are acting as backup tunnels for 65336 and 65337.

PE1#show ip rsvp fast-reroute Primary Protect BW Backup Tunnel I/F BPS:Type Tunnel:Label State Level Type ------ ------- -------- ------------- ------ ----- ------ PE1_t65337 Se1/1.1 0:G Tu65436:0 Ready any-unl Nhop PE1_t65336 Fa2/0 0:G Tu65437:0 Ready any-unl Nhop

I’ll talk more about these tunnels in another post.

By zismail • CCIE SP, Traffic Engineering • 0 • Tags: CCIE SP, TE, Traffic Engineering

Dec 2 2008

How does TE detect a neighbor-down

There are three “down notifications” which cause MPLS nodes to switch traffic onto their FRR backup tunnels.

1-Interface “down notification”

2-RSVP Hello neighbor “down notification”

3-BFD neighbor “down notification”

Some interfaces such as POS have very quick interface down notification ie around 50ms. If a router detects a link down it reroutes the traffic via a backup tunnel.

There are some instances where the router may not experience an interface down due to an intermediary device such as an ethernet switch. In these cases the router can rely on either RSVP hello neighbor “down notifications” or BFD “down notifications”.

RSVP hello protocol mechanics

An RSVP hello enabled router sends out RSVP hellos every interval. An RSVP hello enabled neighbor responds with an RSVP hello Ack. If the sending node does not receive an RSVP hello Ack for four intervals it declares the neighbor as down and notifies FRR.

There are two configurable paramaters for RSVP hellos.

1-Hello interval

2-Number of Ack misses before declaring a neighbor as down.

The hello interval is configured using the following command.

ip rsvp signalling hello fast-reroute refresh interval

The default value is 10000 milliseconds (10 seconds), which is hardly fast convergence. The interval values which can be configured are from 1000 to 30000 (1 to 30 seconds). Which even if use 1 second is not that fast.

The number of Ack misses before declaring a neighbor down can be configured using.

ip rsvp signalling hello fast-reroute refresh misses msg-count

The default for the msg-count argument is 4.

BFD protocol mechanics

BFD establishes a session with neighboring routers. BFD then sends accelerated control messages similar to IGP hellos.

To enable BFD for use with FRR there are two configuration steps.

1-Enable BFD globally

2-Enable BFD at interface level.

To enable BFD globally use the command.

ip rsvp signalling hello bfd

To enable BFD at interface level use the command.

interface gig1/0 ip rsvp signalling hello bfd bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier

BFD has the advantage over RSVP hellos in that it can acheive sub-second convergence.

By zismail • CCIE SP, Traffic Engineering • 2 • Tags: BFD, CCIE SP, TE, Traffic Engineering

Dec 1 2008

Configuring Traffic Engineering using the explicit path-option

Lets start by configuring a dynamic tunnel between PE1 and PE2 using the tunnel configuration below.

interface Tunnel100 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 512 tunnel mpls traffic-eng path-option 1 dynamic

Now lets examine the path the tunnel takes.

PE1#show mpls traffic-eng tunnels tunnel 100

Name: PE1_t100 (Tunnel100) Destination: 3.3.3.3 Status: Admin: up Oper: up Path: valid Signalling: connected

path option 1, type dynamic (Basis for Setup, path weight 20)

Config Parameters: Bandwidth: 512 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 512 bw-based auto-bw: disabled

InLabel : - OutLabel : Serial1/1.1, 20 RSVP Signalling Info: Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 100, Tun_Instance 3 RSVP Path Info: My Address: 10.0.0.1 Explicit Route: 10.0.0.2 10.0.0.6 3.3.3.3 Record Route: NONE Tspec: ave rate=512 kbits, burst=1000 bytes, peak rate=512 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=512 kbits, burst=1000 bytes, peak rate=512 kbits Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 10.0.0.2 10.0.0.6 3.3.3.3 History: Tunnel: Time since created: 4 minutes, 50 seconds Time since path change: 3 minutes, 53 seconds Current LSP: Uptime: 3 minutes, 53 seconds Selection: reoptimation Prior LSP: ID: path option 1 [2] Removal Trigger: configuration changed PE1#

If you examine the Explicit Route you can see the actual path the tunnel takes(Due to the limited topology there is only one path the tunnel could take). If we want we can actually force the tunnel to take this path by defining an explicit path.

Defining an explicit path takes two steps.

Step 1 – Define the explicit-path ie the path the TE tunnel will take

PE1(config)#ip explicit-path name DEBUGALL enable PE1(cfg-ip-expl-path)# PE1(cfg-ip-expl-path)#next-address 10.0.0.2 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 PE1(cfg-ip-expl-path)#next-address 10.0.0.6 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 2: next-address 10.0.0.6 PE1(cfg-ip-expl-path)#next-address 3.3.3.3 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 2: next-address 10.0.0.6 3: next-address 3.3.3.3 PE1(cfg-ip-expl-path)#exit

Step 2 – attach the explicit path to the TE tunnel.

interface Tunnel100 tunnel mpls traffic-eng path-option 1 explicit name DEBUGALL

Verify the tunnel is up and using the explicit path.

PE1#show mpls traffic-eng tunnels tunnel 100

Name: PE1_t100 (Tunnel100) Destination: 3.3.3.3 Status: Admin: up Oper: up Path: valid Signalling: connected

path option 1, type explicit DEBUGALL (Basis for Setup, path weight 20)

Looks good.

By zismail • CCIE SP, Traffic Engineering • 3 • Tags: CCIE SP, TE, Traffic Engineering

Nov 30 2008

Configuring Traffic Engineering

Consider the toplogy below.

We will enable traffic engineering on the serial link between PE1 and P1 and between P1 and PE2.

The first step is to enable traffic engineering globally on all three routers using the command below.

mpls traffic-eng tunnels

Once you have enabled traffic engineering globally, you then need to enable traffic engineering on all the infrastructure links using the command below.

interface Serial1/0.1 point-to-point mpls traffic-eng tunnels

Once you have enabled traffic engineering on the interface you need to decide how much bandwidth per interface you will allow the traffic engineering tunnels to reserve. This can be done with the commands below.

interface Serial1/0.1 point-to-point ip rsvp bandwidth 512

The rsvp value configured here is advertised by IS-IS sub-TLV 10 which is encoded within TLV22. Sub-TLV 9 which is also encoded within TLV22 advertises the Maximum bandwidth of the interface which can be seen as below.

Serial1/0.1 is up, line protocol is up Hardware is M8T-X.21 Internet address is 10.0.0.2/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY Keepalive set (10 sec) Last clearing of "show interface" counters never

We can now view the Traffic Engineering Topology which is constructed using the TE extensions.

if we examine P1s topology we can see two links. It is also worth noting that each link has a TE metric as well as an IGP metric. Also you will notice there are 8 bandwidth entries for each link. We will examine these later, for now its enough to now that they are linked to the priorities of the reservations.

Also worth noting is that currently there are no bandwidth reservations as we havent set up any TE tunnels.

PE1#show mpls traffic-eng topology 2.2.2.2

IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:2 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool Total Allocated Reservable Reservable BW (kbps) BW (kbps) BW (kbps) --------------- ----------- ---------- bw[0]: 0 512 0 bw[1]: 0 512 0 bw[2]: 0 512 0 bw[3]: 0 512 0 bw[4]: 0 512 0 bw[5]: 0 512 0 bw[6]: 0 512 0 bw[7]: 0 512 0

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:2 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool Total Allocated Reservable Reservable BW (kbps) BW (kbps) BW (kbps) --------------- ----------- ---------- bw[0]: 0 1000 0 bw[1]: 0 1000 0 bw[2]: 0 1000 0 bw[3]: 0 1000 0 bw[4]: 0 1000 0 bw[5]: 0 1000 0 bw[6]: 0 1000 0 bw[7]: 0 1000 0

We will now setup a TE tunnel with a bandwidth reservation of 256Kb with the head end of the tunnel on PE1.

interface Tunnel100 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 256 tunnel mpls traffic-eng path-option 1 dynamic end

Once the tunnel has came up, let us reexamine the traffic engineering toplogy of node P1.

PE1#show mpls traffic-eng topology 2.2.2.2
IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:4 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:4 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

As you can see, a reservation of 256Kb is confirmed on the outgoing and NOT incoming interface on P1.

Also, the reservable bandwidth on link[1] has descreased to 744Kb.

Now lets see what happens if we setup another tunnel between PE1 and PE2, however this time we will give the tunnel a priority value of 5 and we will reserve 256Kb for this new tunnel.

The new tunnel will be configured as follows.

interface Tunnel200 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 256 tunnel mpls traffic-eng path-option 1 dynamic

Now lets examine the TE topology for node P1.

PE1#show mpls traffic-eng topology 2.2.2.2

IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:6 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:6 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

As you can see for link[1] there are now 2 reservations, one at priority level 5 and the other at priority level 7.

The other interesting thing to note is the reservable bandwidth values for priority 5 and 7. Priority 7 tunnels now only have 488Kb of reservable bandwidth available whereas priority 5 tunnels have 744Kb of bandwidth available to them. This is due to the fact that priority 5 tunnels have more priority to the bandwidth than priority 7 tunnels. If another priority 5 tunnel requests 744Kb of bandwidth it will receive the bandwidth and the priority 7 tunnel will be “bumbed” ie will have to find another route through the network and if it cannot then it will show as down.

The last thing to do to make the TE tunnel active is to announce the tunnel with the IGP as follows.

interface Tunnel100 tunnel mpls traffic-eng autoroute announce

If we now check the routing table we can see that some routes are visible behind tunnel 100.

PE1#show ip route 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets i L2 2.2.2.2 [115/10] via 10.0.0.2, Serial1/1.1 3.0.0.0/32 is subnetted, 1 subnets i L2 3.3.3.3 [115/20] via 3.3.3.3, Tunnel100 20.0.0.0/30 is subnetted, 1 subnets i L2 20.0.0.0 [115/20] via 10.0.0.2, Serial1/1.1 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.0 is directly connected, Serial1/1.1 i L2 10.0.0.4 [115/20] via 10.0.0.2, Serial1/1.1

However its worth noting, not all subnets are being routed via tunnel 100. I’ll cover this in another post, its important to know when enabling TE which prefixes will use the tunnels.

By zismail • CCIE SP, Traffic Engineering • 1 • Tags: CCIE SP, IS-IS, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – IGP extensions (OSPF)

OSPF has been extended using TLV and sub-TLVs in order to be used with Traffic Engineering.

RFC 3630 contains details of the extensions.

The OSPF TLV extension for TE is also referred to as OSPF Opaque LSA 10. This LSA has an area flooding scope.

Opaque LSA 10 contains 2 top level TLVs.

1. Router Address TLV

2. Link TLV

Router Address TLV

If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the OSPF router ID should be the same as the BGP router ID.

Link TLV

The Link TLV describes a single link. It is composed of a set of sub-TLVs. The key sub-TLVs are:-

Sub-TLV 6 – Maximum bandwidth (4 octets)

Sub-TLV 7 – Maximum reservable bandwidth (4 octets)

Sub-TLV 8 – Unreserved bandwidth (32 octets)

By zismail • CCIE SP, OSPF, Traffic Engineering • 0 • Tags: CCIE SP, OSPF, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – IGP extensions (IS-IS)

Some extensions were added to ISIS to provide resource information to the TE process.

IS-IS Extenstions added to support TE

TLVs have been defined to extend IS-IS functionality to include it amongst the protocols of choice for TE.

Informational RFC 3784 details the TLVs which have been added To IS-IS to support TE. RFC 3874 also introduces the concept of sub-TLVs.

Sub-TLVs have been added to IS-IS. Sub-TLVs are identical to regular TLVs in their structure and layout. They differ however with respect to their location. Sub-TLVs are found within regular TLVs which in turn are found in IS-IS packets.

Sub-TLVs are used to add additional information to the parent TLV.

RFC 3784 extends IS-IS with the following TLVs

1-The Extended IS reachability TLV (TLV type 22). (see section 3 RFC 3784)
2-The Extended IP Reachability TLV (TLV type 135). (see section 4 RFC 3784)
3-The Traffic Engineering Router ID TLV (TLV type 134). (see section 5 RFC 3784)

The Extended IS reachability TLV (TLV type 22)

TLV22 contains many sub-TLVs, the key sub-TLVs required for TE are

Sub-TLV 9: Maximum link bandwidth (section 3.4)
Sub-TLV 10: Maximum reservable link bandwidth (section 3.5)
sub-TLV 11: Unreserved bandwidth (section 3.6)

The Extended IP Reachability TLV (TLV type 135)

TLV135 removes the previous restriction which only allowed a metric range of 0-63. TLV135 provides a 32 bit.

TLV 135 also added one bit(up/down but) to indicate a prefix has been redistributed from level-2 to level-1. This bit is required to prevent routing loops. When a prefix is avertised from level-2 to level-1 the up/down bit is set to 1. Prefixes with the up/down bit set to 1 cannot be advertised to level-2. This is used for loop prevention.

The Traffic Engineering Router ID TLV (TLV type 134)

The router ID TLV contains the 4 octet router ID of the router.

An Important note:- If the loopback address is used as the TE router ID and it is advertised in the IGP as well as BGP then the BGP router ID should be identical to the TE router ID.

By zismail • CCIE SP, IS-IS, Traffic Engineering • 0 • Tags: CCIE SP, IS-IS, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – Introduction

Informational RFC 3272 provides an overview of Traffic Engineering.

Traffic Engineering(TE) is different to network engineering in that TE is concerned about engineering/manipulating traffic flows across the network.

If you think about a road system, network engineering is similar to that of building the roads themselves. Where as TE is analogous to placing the traffic lights, roundabouts and diversions.

In its inception the focus of TE was managing congested networks. Traditional IP networks utilising a link state protocol such as OSPF do not take into account the congestion or utilisation of a link as part of the SPF calculation. TE was seen as a solution to this paradigm, however as like most technologies, TE has evolved to provide other more usefull services to the Traffic Engineer.

Services such as Fast Reroute, load balancing, auto-bandwidth, QoS MPLS TE to name a few.

Most Service Providers today tend to over engineer their networks and not rely on TE to squeeze every bit out of the current network. A network which is 100% utilised is actually putting customer services at risk. If any device or link fails you need idle capacity to reroute and maintain uptime.

By zismail • CCIE SP, Traffic Engineering • 0 • Tags: CCIE SP, TE, Traffic Engineering

Traffic Engineering

Categories

Tags