Let’s consider again the main topology I used so far. I clear all tunnels and reconfigure two TE Tunnels between Headend (POP1-C1) and Tailend (POP3-C2).
First Tunnel will be Tu1132, second one will be Tu11322 (the 2 at the end signals that this is a second tunnel between POP1-C1 (11) and POP3-C2 (32), follow these logic for other multiple tunnels between the same headned and tailend)
What happens when building two TE tunnels between the same headend (1.1.1.5) and tailend(1.1.1.10)? Let’s see:
Before creating any tunnels, Headend Router has all topological information to build its CSPF we know (look at the previous section to have an idea (just an idea) about how CSPF works with PATH list and TENT list with autoroute) that the process starts with putting the Headend at the root of the PATH list to calculate the Explicit Route Object that need to be signalled by RSVP, we can look at this first topological element looking at output of this command:
0001.0001.0015.00 is the isis igp-id of POP1-C1 that identifies itself in the MPLS TE Topological Database. I can see that it has 2 links link[0] and link[1] going respectively to SC3 and to SC1. From a CSPF point of view these links are the same: same reservable bandwidth at each priority level, same igp metric, same TE metric, same attribute-flags (none). Now when POP1-C1 needs to choose one of the link which one it chooses? Since links are equivalent it chooses the first it has in its data structure, then it chooses link[0] because the software write neighbor SC3 first in its database. Now move on in POP1-C1 database and consider neighbor SC3 (the node attached to link[0] of POP1-C1):
NOTE: the brief option hide the BW reservation at each priority levels for the links, but in this example they are all the same.
I can see that SC3 has 7 links and among these links two can be considered on the CSPF calculation toward the destination 1.1.1.10 (we have two possible next-hops):
SC3#show ip cef 1.1.1.10
1.1.1.10/32
nexthop 10.0.23.1 Ethernet0/2 label 2002 ==> link[0]
nexthop 10.0.34.2 Ethernet0/0 label 4002 ==> link[2]
Again, if all other paramenters are matching which one does POP1-C1 choose? It choose the first in the database, again link[0] to next-hop SC2. Now move on in POP1-C1 database and consider neighbor SC2:
On SC2 we have only one possible next-hop to the destination:
SC2#show ip cef 1.1.1.10
1.1.1.10/32
nexthop 10.3.22.2 Ethernet1/1 ==> link[0]
POP1-C1 chooses then link[0] to close its CSPF calculation (we reached the tailend POP3-C2)
Then before configuring any Tunnels to 1.1.1.10 I know that the first MPLS TE Tunnel I will configure to 1.1.1.10 will follow this path:
10.1.13.2 10.0.23.2 10.0.23.1 10.3.22.1 10.3.22.2 1.1.1.10
Let’s check if this is true:
POP1-C1#sh run int Tu1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
Look at how Explicit Route Object matches the expected one. Now it’s time to add a second Tunnel, I name this one Tunnel11322, configuration to apply will be:
POP1-C1#sh run int Tu11322 | b interface
interface Tunnel11322
description POP1-C1-to-POP3-C2-n2
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
before applying it let’s try to understand which Explicit Route Object will be associated to this second tunnel, the logic is the same but this time POP1-C1 must take in account that some links has already reserved bandwidth for the first tunnel, then this time all links are not equivalent:
I can see that link[0] to SC3 has already reserved 1000 Kbit/sec at priority level 7, POP1-C1 then knows that the best link this time for a tunnel of priorty 7 is the link with larger available reservable bandwidth that in this case happens to be link[1] – reservable bandwidth at priority 7 = 7500 Kbps vs 6500 Kbps of link[0]
The choosen next-hop this time should be SC1 (10.1.11.1). Now move on in POP1-C1 database and consider neighbor SC1 (the node attached to link[1] of POP1-C1):
SC1 has two possible next-hop to 1.1.1.10
SC1#show ip cef 1.1.1.10
1.1.1.10/32
nexthop 10.0.12.2 Ethernet0/0 label 2006 ==> link[3]
nexthop 10.0.14.2 Ethernet0/2 label 4001 ==> link[1]
POP1-C1#show mpls traffic-eng topology igp-id isis 0001.0001.0011.00 brief
IGP Id: 0001.0001.0011.00, MPLS TE Id:1.1.1.1 Router Node (isis level-2)
link[0]: Broadcast, DR: 0001.0001.0011.05, nbr_node_id:10, gen:9
frag_id 0, Intf Address:10.2.21.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[1]: Broadcast, DR: 0001.0001.0011.03, nbr_node_id:22, gen:9
frag_id 0, Intf Address:10.0.14.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[2]: Broadcast, DR: 0001.0001.0011.02, nbr_node_id:2, gen:9
frag_id 0, Intf Address:10.0.13.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[3]: Broadcast, DR: 0001.0001.0011.01, nbr_node_id:20, gen:9
frag_id 0, Intf Address:10.0.12.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[4]: Broadcast, DR: 0001.0001.0015.03, nbr_node_id:29, gen:9
frag_id 0, Intf Address:10.1.11.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[5]: Broadcast, DR: 0001.0001.0016.04, nbr_node_id:4, gen:9
frag_id 0, Intf Address:10.1.21.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[6]: Broadcast, DR: 0001.0001.0017.03, nbr_node_id:33, gen:9
frag_id 0, Intf Address:10.2.11.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
Again, link[1] and link[3] are equivalent if we look at reservable bandwidth, IGP metric, TE metric and so on.., because no Tunnel is flowing through links of SC1, the first link listed in database is link[1], then the choosen next-hop should be 10.0.14.2 (SC4). On SC4 we have only one possible next-hop to 1.1.1.10
SC4#sh ip cef 1.1.1.10
1.1.1.10/32
nexthop 10.3.24.1 Ethernet1/0 ==> 10.3.24.2
The expected calculated Explicit Route Object for this second tunnel will be:
10.1.11.1 10.0.14.1 10.0.14.2 10.3.24.2 10.3.24.1 1.1.1.10
Let’s verify this configuring the second Tunnel (11322):
POP1-C1(config)#interface Tunnel11322
POP1-C1(config-if)# description POP1-C1-to-POP3-C2-n2
POP1-C1(config-if)# ip unnumbered Loopback0
POP1-C1(config-if)# tunnel mode mpls traffic-eng
POP1-C1(config-if)# tunnel destination 1.1.1.10
POP1-C1(config-if)# tunnel mpls traffic-eng autoroute announce
POP1-C1(config-if)# tunnel mpls traffic-eng priority 7 7
POP1-C1(config-if)# tunnel mpls traffic-eng bandwidth 1000
POP1-C1(config-if)# tunnel mpls traffic-eng path-option 10 dynamic
*Mar 17 09:21:09.460: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11322, changed state to down
*Mar 17 09:21:09.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11322, changed state to up
You can see that again the expected ERO matches the one built by POP1-C1 after configuring the second tunnel. Here the reserved bandwidth on each node:
POP1-C1#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et1/2 ena 1M 7500K 7500K 0 ==> Tu11322
Et1/3 ena 1M 7500K 7500K 0 ==> Tu1132
SC1#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et0/0 ena 0 7500K 7500K 0
Et0/1 ena 0 7500K 7500K 0
Et0/2 ena 1M 7500K 7500K 0 ==> Tu11322
Et1/0 ena 0 7500K 7500K 0
Et1/1 ena 0 7500K 7500K 0
Et1/2 ena 0 7500K 7500K 0
Et1/3 ena 0 7500K 7500K 0
SC3#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et0/0 ena 0 7500K 7500K 0
Et0/1 ena 0 7500K 7500K 0
Et0/2 ena 1M 7500K 7500K 0 ==> Tu1132
Et1/0 ena 0 7500K 7500K 0
Et1/1 ena 0 7500K 7500K 0
Et1/2 ena 0 7500K 7500K 0
Et1/3 ena 0 7500K 7500K 0
SC2#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et0/0 ena 0 7500K 7500K 0
Et0/1 ena 0 7500K 7500K 0
Et0/2 ena 0 7500K 7500K 0
Et1/0 ena 0 7500K 7500K 0
Et1/1 ena 1M 7500K 7500K 0 ==> Tu1132
Et1/2 ena 0 7500K 7500K 0
Et1/3 ena 0 7500K 7500K 0
SC4#sh ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et0/0 ena 0 7500K 7500K 0
Et0/1 ena 0 7500K 7500K 0
Et0/2 ena 0 7500K 7500K 0
Et1/0 ena 1M 7500K 7500K 0 ==> Tu11322
Et1/1 ena 0 7500K 7500K 0
Et1/2 ena 0 7500K 7500K 0
Et1/3 ena 0 7500K 7500K 0
You can see the established paths in the following picture:
Now, looking at the picture, there are other possible paths between Headend and Tailend (the dashed black and yellow one), what happens if I configure a third (Tu11323) and fourth (Tu11324) tunnels? One may expect that these other 2 new tunnels go to run over these other not yet used paths. Let’s try:
POP1-C1#sh run int Tu11323 | b interface
interface Tunnel11323
description POP1-C1-to-POP3-C2-n3
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et1/2 ena 1M 7500K 7500K 0
Et1/3 ena 2M 7500K 7500K 0
POP1-C1 can choose among two links, when two tunnels are present the links are again equivalent and then POP1-C1 chooses the first in its data structure, then goes to SC3.
SC3#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et0/0 ena 0 7500K 7500K 0
Et0/1 ena 0 7500K 7500K 0
Et0/2 ena 2M 7500K 7500K 0
Et1/0 ena 0 7500K 7500K 0
Et1/1 ena 0 7500K 7500K 0
Et1/2 ena 0 7500K 7500K 0
Et1/3 ena 0 7500K 7500K 0
At SC3 the choosen next-hop is again SC2 and not SC4 though the link between SC3 and SC4 e0/0 has more bandwidth available to be reserved. Look at the Explicit Route Object of this third Tunnel:
Explicit Route Object match the one of the first Tunnel Tu1132: 10.1.13.2 10.0.23.2 10.0.23.1 10.3.22.1 10.3.22.2 1.1.1.10
Why does this happen? Because CSPF doesn’t make load sharing (as SPF does) it calculate one possible path to the tailend that respect constraints but how it results strcitly depends on how CSPF is software implemented in IOS.
If now I configure a fourth tunnel Tu11324 I can see that it will take the same path of the second one (Tu11322), let’s see:
POP1-C1#sh run int Tu11324 | b interface
interface Tunnel11324
description POP1-C1-to-POP3-C2-n4
no ip address
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show mpls traffic-eng tunnels Tu11324 | b Explicit Route
Explicit Route: 10.1.11.1 10.0.14.1 10.0.14.2 10.3.24.2
10.3.24.1 1.1.1.10
Record Route: NONE
Tspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.1.13.1 10.1.13.2 10.0.23.2 10.0.23.1
10.3.22.1 10.3.22.2 1.1.1.10
Then with four active tunnel from the same Headend (1.1.1.5) to the same Tailend (1.1.1.10) I have:
Now, as last thing to close this (too long) discussion, configure another Loopback on the headend:
POP1-C1#sh run int Lo99 | b interface
interface Loopback99
ip address 99.99.99.15 255.255.255.255
ip router isis CORE
switch the mpls traffic-eng router-id from Lo0 to Lo99:
POP1-C1(config)#router isis CORE
POP1-C1(config-router)#mpls traffic-eng router-id Lo99
shut all 4 tunnels and no shut them, then look at the new four EROs from all 4 tunnels:
POP1-C1#show mpls traffic-eng tunnels Tu1132 | b Explicit Route
Explicit Route: 10.1.13.2 10.0.34.1 10.0.34.2 10.3.24.2
10.3.24.1 1.1.1.10
POP1-C1#show mpls traffic-eng tunnels Tu11322 | b Explicit Route
Explicit Route: 10.1.13.2 10.0.23.2 10.0.23.1 10.3.22.1
10.3.22.2 1.1.1.10
POP1-C1#show mpls traffic-eng tunnels Tu11323 | b Explicit Route
Explicit Route: 10.1.11.1 10.0.14.1 10.0.14.2 10.3.24.2
10.3.24.1 1.1.1.10
POP1-C1#show mpls traffic-eng tunnels Tu11324 | b Explicit Route
Explicit Route: 10.1.13.2 10.0.23.2 10.0.23.1 10.3.22.1
10.3.22.2 1.1.1.10
The following picture summarize the new paths:
You see that we have a different scenario about calculated paths when we use Lo99 instead of Lo0 to originate the Tunnels. Why does this happen? I don’t know exactly which algorithm and data structure IOS uses in building the paths, maybe that some interactions with CEF table is behind the scene here, for example if I look at:
POP1-C1#show ip cef exact-route 1.1.1.5 1.1.1.10
1.1.1.5 -> 1.1.1.10 => label 3077 TAG adj out of Ethernet1/3, addr 10.1.13.2
POP1-C1#show ip cef exact-route 99.99.99.5 1.1.1.10
99.99.99.5 -> 1.1.1.10 => label 1074 TAG adj out of Ethernet1/2, addr 10.1.11.1
Then it could happen that the IP adresses used to source the tunnel influences path building. Anyway the most important thing to remember after all these examples is that if you build dynamically many tunnels between the same headend and the same tailend, and there are more than one possible paths from source to destination, don’t expect that all the Tunnels will be equally distributed among all possible paths, also you cannot know exactly which path is choosen if all the paths are equivalent in terms of Constraints to the SPF. Even when there are instability of links in the network maybe that the same tunnels runs over different path when instability is resolved.
Depending on what you are trying to achieve with your Traffic-Engineering soultion, it would be necessary to have a more deterministic control over the paths taken by a tunnel. To do that IOS gives some tool to influence the CSPF calculation:
1] Static Tunnel
2] attribute-flags
3] metric weights
Of course in some scenario is accceptable to have dynamic tunnels that runs over one of the possible path and in other scenario that could not be acceptable.
For example suppose I want use all the 4 possible paths between POP1-C1 and POP3-C2 and that eache one of the four tunnel runs over one of the path, I saw above that letting IOS building dynamically the tunnel is not enough to reach what I would implement.
First solution I have is to build a STATIC TUNNEL. Let’s suppose I want tunnel Tu1132 running over the black dashed path (POP1-C1 -> SC1 -> SC2 -> POP3-C2):
——- NOTE ——-
If you have some already configured Tunnels that point to one Loopback interfaces, if you change the mpls traffic-eng router-id to another Loopback, the configuration of the tunnel doesn’t reflect the change, but RSVP signalling goes from the new configured router-id
POP1-C1#sh run int Tu1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
router isis CORE
mpls ldp autoconfig level-2
mpls traffic-eng router-id Loopback99
mpls traffic-eng level-2
net 49.0001.0001.0015.00
metric-style wide
log-adjacency-changes
redistribute isis ip level-2 into level-1 route-map LVL2-TO-LVL1
POP1-C1#sh int Tu1132 | i source
Tunnel source 99.99.99.15, destination 1.1.1.10
——- END NOTE ——-
I delete Lo99 and restore mpls traffic-eng router-id to Lo0. Configuration of the tunnel was:
POP1-C1#sh run int Tu1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
The path option gives me the possibility to have more than one method to build the tunnel, the preference controls (low preference are better) which method comes first:
Enter configuration commands, one per line. End with CNTL/Z.
POP1-C1(config)#int Tu1132
POP1-C1(config-if)#shut
POP1-C1(config-if)#tunnel mpls traffic-eng path-option ?
<1-1000> preference for this path option
protect a path protection setup option
POP1-C1(config-if)#tunnel mpls traffic-eng path-option 5 ?
dynamic setup based on dynamically calculcated path
explicit setup based on preconfigured path
POP1-C1(config-if)#tunnel mpls traffic-eng path-option 5 explicit ?
identifier Specify an IP explicit path by number
name Specify an IP explicit path by name
POP1-C1(config-if)#tunnel mpls traffic-eng path-option 5 explicit name BLACK
POP1-C1(config)#ip explicit-path ?
identifier Specify explicit path by number
name Specify explicit path by name
POP1-C1(config)#ip explicit-path name BLACK ?
disable disable the explicit path
enable enable the explicit path
<cr>
POP1-C1(config)#ip explicit-path name BLACK enable ?
<cr>
POP1-C1(config)#ip explicit-path name BLACK enable
POP1-C1(cfg-ip-expl-path)#?
Explicit-Path configuration commands:
append-after Append additional entry after specified index
exclude-address Exclude an address from subsequent partial path segments
exit Exit from explicit-path configuration mode
index Specify the next entry index to add, edit (or delete)
list Re-list all or part of the explicit path entries
next-address Specify the next address in the path
no Delete a specific explicit-path entry index
POP1-C1(cfg-ip-expl-path)#next-address ?
WORD Enter IP address (A.B.C.D)
loose Target address is loose
strict Target address is strict
POP1-C1#sh run | s ip explicit
ip explicit-path name BLACK enable
next-address 1.1.1.5
next-address 10.1.11.1
next-address 10.0.12.2
next-address 10.3.22.2
next-address 1.1.1.10
Practically speaking I configured an Explicit Route Object, let’s unshut the tunnel:
POP1-C1#show run int TU1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
shutdown
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 5 explicit name BLACK
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1(config)#int Tu1132
POP1-C1(config-if)#no shut
*Mar 17 14:14:54.205: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1132, changed state to up
POP1-C1#show mpls traffic-eng tunnels tu1132
Name: POP1-C1-to-POP3-C2-n1 (Tunnel1132) Destination: 1.1.1.10
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 5, type explicit BLACK (Basis for Setup, path weight 30)
path option 10, type dynamic
Config Parameters:
Bandwidth: 1000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 1000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 5 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : –
OutLabel : Ethernet1/2, 1077
RSVP Signalling Info:
Src 1.1.1.5, Dst 1.1.1.10, Tun_Id 1132, Tun_Instance 25
RSVP Path Info:
My Address: 10.1.11.2
Explicit Route: 10.1.11.1 10.0.12.1 10.0.12.2 10.3.22.1
10.3.22.2 1.1.1.10
Record Route: NONE
Tspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.1.13.1 10.1.13.2 10.0.23.2 10.0.23.1
10.3.22.1 10.3.22.2 1.1.1.10
History:
Tunnel:
Time since created: 6 hours, 4 minutes
Time since path change: 12 seconds
Number of LSP IDs (Tun_Instances) used: 25
Current LSP:
Uptime: 12 seconds
Prior LSP:
ID: path option 5 [24]
Removal Trigger: tunnel shutdown
Now I have Tunnel1132 on the black path. If something goes wrong on this path, the dynamic option with preference 10 grants that the tunnel can rebuild automatically a path around the fault.
Let’s use a different approach to influence path selection of second tunnel Tunnel11322 making this Tunnels running over the orange path, another option I have to do this, is using attributes-flags on each link and affinity on the Tunnel interface. Attributes flags are simply bit markers of the links crossed by a tunnel, we can arrange things in such a way that Tunnels cross only links with common attributes, we are free to associate the meaning we want to the attribute, for example in this case I will mark links with decimal value 2 and 2 for me in this case means = link belongs to orange path.
The physical links along the orange path are:
POP1-C1 e1/2 10.1.11.2
SC1 e1/2 10.1.11.1
SC1 e0/2 10.0.14.1
SC4 e0/2 10.0.14.2
SC4 e1/0 10.3.24.2
POP3-C2 e1/0 10.3.24.1
Let’s start from the tailend:
POP3-C2(config)#int e1/0
POP3-C2(config-if)#mpls traffic-eng attribute-flags ?
<0x0-0xFFFFFFFF> Attribute flags
Attribute flags are 32 bits value, the value I selected is decimal 2 that translates into ==> 0x00000002
POP3-C2(config)#int e1/0
POP3-C2(config-if)#mpls traffic-eng attribute-flags 0x00000002
SC4(config)#int e1/0
SC4(config-if)# mpls traffic-eng attribute-flags 0x2
SC4(config)#int e0/2
SC4(config-if)# mpls traffic-eng attribute-flags 0x2
SC1(config)#int e0/2
SC1(config-if)# mpls traffic-eng attribute-flags 0x2
SC1(config)#int e1/2
SC1(config-if)# mpls traffic-eng attribute-flags 0x2
POP1-C1(config)#int e1/2
POP1-C1(config-if)#mpls traffic-eng attribute-flags 0x2
Before making the Tunnel11322 interface attribute-flags aware, let’s check how isis advertised the flags:
POP1-C1#show mpls traffic-eng topology igp-id isis 0001.0001.0015.00 brief
IGP Id: 0001.0001.0015.00, MPLS TE Id:1.1.1.5 Router Node (isis level-2)
link[0]: Broadcast, DR: 0001.0001.0015.04, nbr_node_id:78, gen:178
frag_id 0, Intf Address:10.1.13.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
link[1]: Broadcast, DR: 0001.0001.0015.03, nbr_node_id:97, gen:178
frag_id 0, Intf Address:10.1.11.2
TE metric:10, IGP metric:10, attribute flags:0x2
SRLGs: None
POP1-C1#show mpls traffic-eng topology igp-id isis 0001.0001.0011.00 brief
IGP Id: 0001.0001.0011.00, MPLS TE Id:1.1.1.1 Router Node (isis level-2)
[—-omitted—-]
link[4]: Broadcast, DR: 0001.0001.0015.03, nbr_node_id:97, gen:179
frag_id 0, Intf Address:10.1.11.1
TE metric:10, IGP metric:10, attribute flags:0x2
SRLGs: None
[—-omitted—-]
The same for the other links, now I configure Tunnel11322 to look at attributes flags:
POP1-C1(config)#int Tu11322
POP1-C1(config-if)#shut
POP1-C1(config-if)#tunnel mpls traffic-eng affinity ?
<0x0-0xFFFFFFFF> affinity value
POP1-C1(config-if)#tunnel mpls traffic-eng affinity 0x2 ?
mask mask on desired link attributes
<cr>
POP1-C1(config-if)#tunnel mpls traffic-eng affinity 0x2 mask 0x3
Having to do with hexadecimal values and mask could be scaring but here is what this command means:
0x2 = 00000000000000000000000000000010
0x3 = 00000000000000000000000000000011 ==> as usual a 1 in the mask must match the corresponding bit in the value
Then here we are telling POP1-C1 to look if links have attributes, if they have them, POP1-C1 looks at the last two bits in the value, if these last 2 bits are 10 (=2) then link can be used to build the tunnels, otherwise link cannot be used. The association flag 0x2 = orange path is in my mind. Let’s unshut the tunnel and verify:
POP1-C1(config)#int Tu11322
POP1-C1(config-if)#no shut
*Mar 17 15:07:20.721: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11322, changed state to up
POP1-C1#sh run int Tu11322 | b interface
interface Tunnel11322
description POP1-C1-to-POP3-C2-n2
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x2 mask 0x3
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show mpls traffic-eng tunnels Tu11322
Name: POP1-C1-to-POP3-C2-n2 (Tunnel11322) Destination: 1.1.1.10
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type dynamic (Basis for Setup, path weight 30)
Config Parameters:
Bandwidth: 1000 kbps (Global) Priority: 7 7 Affinity: 0x2/0x3
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 1000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : –
OutLabel : Ethernet1/2, 1075
RSVP Signalling Info:
Src 1.1.1.5, Dst 1.1.1.10, Tun_Id 11322, Tun_Instance 16
RSVP Path Info:
My Address: 10.1.11.2
Explicit Route: 10.1.11.1 10.0.14.1 10.0.14.2 10.3.24.2
10.3.24.1 1.1.1.10
Record Route: NONE
Tspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.1.13.1 10.1.13.2 10.0.23.2 10.0.23.1
10.3.22.1 10.3.22.2 1.1.1.10
History:
Tunnel:
Time since created: 5 hours, 49 minutes
Time since path change: 3 minutes, 18 seconds
Number of LSP IDs (Tun_Instances) used: 16
Current LSP:
Uptime: 3 minutes, 18 seconds
Prior LSP:
ID: path option 10 [15]
Removal Trigger: tunnel shutdown
I can see that the tunnel is built over the wanted orange path (POP1-C1 ==> SC1 ==> SC4 ==> POP3-C2, see picture above (link)).
Third method I have to influence CSPF computation is using metric weights, by default the metric of the established Tunnel reflects the one calculated by the IGP because, for example:
POP1-C1#show mpls traffic-eng tunnels Tu1132 | i path weight|Metric
path option 10, type dynamic (Basis for Setup, path weight 30) ==> 30 is the total cost over the tunnel to reach the tailend router
Metric Type: TE (default) ==> the type of metric is by default Traffic Eng Metric that collapses on the IGP if the default is not changed.
On each physical link I can configure the interface such that IGP advertise a metric for the tunnel different from the one associated to the IGP, for example in this example with all default configuration about metric all the tunnel will have the same metric of 30. I suppose I want to have two preferred paths (the yellow path POP1-C1 ==> SC3 ==> SC4 ==> POP3-C2) and the green path (giving POP1-C1 ==> SC3 ==> SC2 ==> POP3-C2) giving them TE metric of 15 instead of 30, I will use also explicit path and attribute-flags to force tunnels over the path I want. I will clear all attributes-flags and explicit path and I work on a global solution:
Here is my plan:
Tu1132 must follow the BLACK path and have a metric of 30
Tu11322 must follow the ORANGE path and have a metric of 30
Tu11323 must follow the GREEN path and have a metric of 25
Tu11324 must follow the YELLOW path and have a metric of 15
I’ll shut all the tunnels and clear configuration about explicit path and attribute-flags and weights.
Now, to respect my plan links connected to interface e1/2 and e1/3 of POP1-C1 should both carry two Tunnels (Tu1132 and Tu11322 on e1/2 and Tu11323 and Tu11324 on e1/3).
I will use attributes-flags to setup the first two, then I have to find a way to mark a link as able to carry both tunnels or only one of the tunnel:
0x1 ==> 00000000000000000000000000000001 ==> maps to Black Path
0x2 ==> 00000000000000000000000000000010 ==> maps to Orange Path
0x3 ==> 00000000000000000000000000000011 ==> maps to Orange or Black Paths (note this last one is the logical or of the first two)
To set up the first tunnel I configured these link attributes:
POP3-C2#sh run int e1/1 | b interface
interface Ethernet1/1
ip address 10.3.22.2 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x1
ip rsvp bandwidth percent 75
SC2#sh run int e1/1 | b interface
interface Ethernet1/1
ip address 10.3.22.1 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x1
ip rsvp bandwidth percent 75
SC2#sh run int e0/0 | b interface
interface Ethernet0/0
ip address 10.0.12.2 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x1
ip rsvp bandwidth percent 75
SC1#sh run int e0/0 | b interface
interface Ethernet0/0
ip address 10.0.12.1 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x1
ip rsvp bandwidth percent 75
SC1#sh run int e1/2 | b interface
interface Ethernet1/2
ip address 10.1.11.1 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x3
ip rsvp bandwidth percent 75
POP1-C1#sh run int e1/2 | b interface
interface Ethernet1/2
ip address 10.1.11.2 255.255.255.252
ip router isis CORE
mpls traffic-eng tunnels
mpls traffic-eng attribute-flags 0x3
ip rsvp bandwidth percent 75
POP1-C1#sh run int Tu1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x1 mask 0x1
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
I can see that every link is marked with flags 0x1 meaning that the link belongs to black path, only link connected to interfaces 1/2 between SC1 and POP1-C1 are flagged with flags 0x3 meaning that link belongs to Black Path or Orange Path. Tunnel interface 1132 has an affinity of 0x1 and a mask of 0x1, then when POP1-C1 tries to calculate its CSPF, it checks for the last bit of the attribute flags that are advertised for each link, if this bit is = 1 link is usable by the tunnel, if is not 1 the link is not usable by this tunnel. When POP1-C1 evaluates the attribut flags of the link connecting to SC1 it finds that this link has a flag = 0x3 and the last bit is = 1 then it can use it.
POP1-C1#show mpls traffic-eng tunnels Tu1132 | b Explicit Route
Explicit Route: 10.1.11.1 10.0.12.1 10.0.12.2 10.3.22.1
10.3.22.2 1.1.1.10
Outputs confirms that the Tunnel is built over the Black Path. Now, let’s build the second tunnel over the Orange Path (POP1-C1 ==> SC1 ==> SC4 ==> POP3-C2)
POP3-C2(config)#int e1/0
POP3-C2(config-if)#mpls traffic-eng attribute-flags 0x2
SC4(config)#int e1/0
SC4(config-if)#mpls traffic-eng attribute-flags 0x2
SC4(config)#int e0/2
SC4(config-if)#mpls traffic-eng attribute-flags 0x2
SC1(config)#int e0/2
SC1(config-if)#mpls traffic-eng attribute-flags 0x2
SC1#show run int e1/2 | i flag
mpls traffic-eng attribute-flags 0x3 ==> already configured when I set up TU1132
POP1-C1#sh run int e1/2 | i flag
mpls traffic-eng attribute-flags 0x3 ==> already configured when I set up TU1132
POP1-C1(config)#interface Tunnel11322
POP1-C1(config-if)# description POP1-C1-to-POP3-C2-n2
POP1-C1(config-if)# ip unnumbered Loopback0
POP1-C1(config-if)# shutdown
POP1-C1(config-if)# tunnel mode mpls traffic-eng
POP1-C1(config-if)# tunnel destination 1.1.1.10
POP1-C1(config-if)# tunnel mpls traffic-eng autoroute announce
POP1-C1(config-if)# tunnel mpls traffic-eng priority 7 7
POP1-C1(config-if)# tunnel mpls traffic-eng bandwidth 1000
POP1-C1(config-if)# tunnel mpls traffic-eng affinity 0x2 mask 0x2
POP1-C1(config-if)# tunnel mpls traffic-eng path-option 10 dynamic
*Mar 22 14:29:14.851: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11322, changed state to down
*Mar 22 14:29:15.924: %LINK-5-CHANGED: Interface Tunnel11322, changed state to administratively down
POP1-C1(config-if)#no shut
*Mar 22 14:29:40.559: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11322, changed state to up
POP1-C1#sh run int Tu11322 | b interface
interface Tunnel11322
description POP1-C1-to-POP3-C2-n2
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x2 mask 0x2
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
Below output confirms that second Tunnel11322 runs over the Orange Path:
POP1-C1#show mpls traffic-eng tunnels Tu11322 | b Explicit Route
Explicit Route: 10.1.11.1 10.0.14.1 10.0.14.2 10.3.24.2
10.3.24.1 1.1.1.10
POP1-C1#show ip rsvp interface
interface rsvp allocated i/f max flow max sub max VRF
Et1/2 ena 2M 7500K 7500K 0 ==> Et1/2 is carrying both tunnels (each reserving 1M)
Et1/3 ena 0 7500K 7500K 0
POP1-C1#show mpls traffic-eng tunnels | i Tunn|path weight|Metric
Name: POP1-C1-to-POP3-C2-n1 (Tunnel1132) Destination: 1.1.1.10
path option 10, type dynamic (Basis for Setup, path weight 30)
Metric Type: TE (default)
Tunnel:
Name: POP1-C1-to-POP3-C2-n2 (Tunnel11322) Destination: 1.1.1.10
path option 10, type dynamic (Basis for Setup, path weight 30)
Metric Type: TE (default)
Tunnel:
I see that Tunnels have a path weight of 30 as wanted. Look also at how Headend loads share among all possible paths (two isis IGP paths via POP3-C1 (1.1.1.9) and two Tunnels)
POP1-C1#show ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 50, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11322, 01:12:53 ago
Routing Descriptor Blocks:
10.1.13.2, from 1.1.1.9, 01:12:53 ago, via Ethernet1/3
Route metric is 50, traffic share count is 1
* 10.1.11.1, from 1.1.1.9, 01:12:53 ago, via Ethernet1/2
Route metric is 50, traffic share count is 1
1.1.1.10, from 1.1.1.10, 01:12:53 ago, via Tunnel11322
Route metric is 50, traffic share count is 1
1.1.1.10, from 1.1.1.10, 01:12:53 ago, via Tunnel1132
Route metric is 50, traffic share count is 1
Let’s move forward and configure the last two tunnels, for the third one Tu11323 I will use an explicit path:
POP1-C1(config)#ip explicit-path name GREEN enable
POP1-C1(cfg-ip-expl-path)# next-address 1.1.1.5
Explicit Path name GREEN:
1: next-address 1.1.1.5
POP1-C1(cfg-ip-expl-path)# next-address 10.1.13.2
Explicit Path name GREEN:
1: next-address 1.1.1.5
2: next-address 10.1.13.2
POP1-C1(cfg-ip-expl-path)# next-address 10.0.23.1
Explicit Path name GREEN:
1: next-address 1.1.1.5
2: next-address 10.1.13.2
3: next-address 10.0.23.1
POP1-C1(cfg-ip-expl-path)# next-address 10.3.22.2
Explicit Path name GREEN:
1: next-address 1.1.1.5
2: next-address 10.1.13.2
3: next-address 10.0.23.1
4: next-address 10.3.22.2
POP1-C1(cfg-ip-expl-path)# next-address 1.1.1.10
Explicit Path name GREEN:
1: next-address 1.1.1.5
2: next-address 10.1.13.2
3: next-address 10.0.23.1
4: next-address 10.3.22.2
5: next-address 1.1.1.10
POP1-C1#sh run int Tu11323 | b interface
interface Tunnel11323
description POP1-C1-to-POP3-C2-n3
ip unnumbered Loopback0
shutdown
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 5 explicit name GREEN
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
When I configure the Tunnel and no shut it, line protocol on the tunnel doesn’t go up signalling some problem:
POP1-C1(config)#int tu11323
POP1-C1(config-if)#no shut
*Mar 22 15:59:53.245: %LINK-3-UPDOWN: Interface Tunnel11323, changed state to up ==> LINK goes up but LINE PROTOCOL stays down:
POP1-C1#show int Tu11323 | i Tunnel11323
Tunnel11323 is up, line protocol is down
Why? I configured both an explicit and a dynamic method for backup, here is not working neither the explicit path nor the dynamic one:
POP1-C1#show mpls traffic-eng tunnels Tu11323 | i Error
Last Error: PCALC:: No path to destination, 0001.0001.0110.00
POP1-C1 is telling me that it has no path available for the destination 1.1.1.10, let’s remove the explicit option and let’s see if the dynamic option find its way to 1.1.1.10:
POP1-C1(config)#int Tu11323
POP1-C1(config-if)#no mpls traffic-eng path-option 5 explicit name GREEN
POP1-C1(config-if)#no shut
POP1-C1(config-if)#
*Mar 22 16:38:36.294: %LINK-3-UPDOWN: Interface Tunnel11323, changed state to up ==> LINK goes up but LINE PROTOCOL stays down:
POP1-C1#show mpls traffic-eng tunnels Tu11323 | i Error
Last Error: PCALC:: No path to destination, 0001.0001.0110.00
Now, though POP1-C1 tries to find dynamically a way to reach the tailend it results in ending either on SC2 or on SC4 to go to POP3-C2 and both has their link configured with attributes-flags dedicated to the first two tunnels:
SC2#sh run int e1/1 | i flags
mpls traffic-eng attribute-flags 0x1
SC4#sh run int e1/0 | i flags
mpls traffic-eng attribute-flags 0x2
Then, I need to tell POP1-C1 don’t care about attributes-flags, use any possible links, how can I do?:
Restoring the explicit path option:
POP1-C1(config)#int Tu11323
POP1-C1(config-if)# tunnel mpls traffic-eng path-option 5 explicit name GREEN
and configure the tunnel in such a way that it doens’t consider attribute-flags:
POP1-C1(config-if)#tunnel mpls traffic-eng affinity 0x0 mask 0x0
POP1-C1(config-if)#
*Mar 22 16:55:45.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11323, changed state to up
Setting a mask of all 0s means ==> don’t look at any bits, by default instead if some links has attribute-flags Tunnel cannot use them if affinity doesn’t match.
POP1-C1#sho int Tu11323 | i Tunnel11323
Tunnel11323 is up, line protocol is up
POP1-C1#show mpls traffic-eng tunnels Tu11323
Name: POP1-C1-to-POP3-C2-n3 (Tunnel11323) Destination: 1.1.1.10
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 5, type explicit GREEN (Basis for Setup, path weight 30)
path option 10, type dynamic
Config Parameters:
Bandwidth: 1000 kbps (Global) Priority: 7 7 Affinity: 0x0/0x0
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 1000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 5 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : –
OutLabel : Ethernet1/3, 3074
RSVP Signalling Info:
Src 1.1.1.5, Dst 1.1.1.10, Tun_Id 11323, Tun_Instance 35
RSVP Path Info:
My Address: 10.1.13.1
Explicit Route: 10.1.13.2 10.0.23.2 10.0.23.1 10.3.22.1
10.3.22.2 1.1.1.10
Record Route: NONE
Tspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.1.13.1 10.1.13.2 10.0.23.2 10.0.23.1
10.3.22.1 10.3.22.2 1.1.1.10
History:
Tunnel:
Time since created: 4 hours, 53 minutes
Time since path change: 4 hours, 53 minutes
Number of LSP IDs (Tun_Instances) used: 35
Current LSP:
Uptime: 4 hours, 53 minutes
Tunnel 11323 now follows the explicit configured path and has a Metric of 30, now routing table about 1.1.1.10 is:
POP1-C1#sh ip route 1.1.1.10
Routing entry for 1.1.1.10/32
Known via “isis”, distance 115, metric 40, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel1132, 04:55:37 ago
Routing Descriptor Blocks:
1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel1132
Route metric is 40, traffic share count is 1
1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel11323
Route metric is 40, traffic share count is 1
* 1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel11322
Route metric is 40, traffic share count is 1
If I want Tunnel11323 to have a metric of 25 I can do:
POP1-C1(config)#int Tu11323
POP1-C1(config-if)#tunnel mpls traffic-eng autoroute metric 25
POP1-C1#show run int Tu11323 | b interface
interface Tunnel11323
description POP1-C1-to-POP3-C2-n3
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric 25
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name GREEN
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show ip route 1.1.1.10
Routing entry for 1.1.1.10/32
Known via “isis”, distance 115, metric 35, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11323, 00:00:46 ago
Routing Descriptor Blocks:
* 1.1.1.10, from 1.1.1.10, 00:00:46 ago, via Tunnel11323
Route metric is 35, traffic share count is 1
Now I have the third Tunnel preferred over the other twos. If you now looked again at the output of “show mpls traffic-eng tunnels Tunnel11323” you could see that outputs match exactly, this is because the command “tunnel mpls traffic-eng autoroute metric 25” has only local influence on the Headend Router and does’nt change PATH calculation or RSVP info advertised to other routers. This happens because all modifications to the tunnel metric are done AFTER the CSPF is already calculated, and then changing the metric of the tunnel doesn’t change which routes are installed through the tunnel interface but only the costs associated to these routes.
In this example before setting this command you see three routes:
POP1-C1#sh ip route 1.1.1.10
Routing entry for 1.1.1.10/32
Known via “isis”, distance 115, metric 40, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel1132, 04:55:37 ago
Routing Descriptor Blocks:
1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel1132
Route metric is 40, traffic share count is 1
1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel11323
Route metric is 40, traffic share count is 1
* 1.1.1.10, from 1.1.1.10, 04:55:37 ago, via Tunnel11322
Route metric is 40, traffic share count is 1
After changing the metric you still have the three available paths but for one of them you have a better metric.
POP1-C1#show ip route 1.1.1.10
Routing entry for 1.1.1.10/32
Known via “isis”, distance 115, metric 35, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11323, 00:03:33 ago
Routing Descriptor Blocks:
* 1.1.1.10, from 1.1.1.10, 00:03:33 ago, via Tunnel11323
Route metric is 35, traffic share count is 1
Last step to complete my scenario is to add last tunnel:
POP1-C1#show run | s name YELLOW
ip explicit-path name YELLOW enable
next-address 1.1.1.15
next-address 10.1.13.2
next-address 10.0.34.2
next-address 10.3.24.2
next-address 1.1.1.10
POP1-C1#show run int Tu11324 | b interface
interface Tunnel11324
description POP1-C1-to-POP3-C2-n4
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric 15
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name YELLOW
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show mpls traffic-eng tunnels tunnel 11324 | b Explicit Route
Explicit Route: 10.1.13.2 10.0.34.1 10.0.34.2 10.3.24.2
10.3.24.1 1.1.1.10
Now the preferred path is the last one I configured:
POP1-C1#show ip route 1.1.1.10
Routing entry for 1.1.1.10/32
Known via “isis”, distance 115, metric 25, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11324, 00:02:09 ago
Routing Descriptor Blocks:
* 1.1.1.10, from 1.1.1.10, 00:02:09 ago, via Tunnel11324
Route metric is 25, traffic share count is 1
Picture below shows the four paths:
POP1-C1#show ip route | i Tu
i L2 1.1.1.10 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 1.1.1.17 [115/35] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 1.1.1.18 [115/35] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 10.3.22.0/30 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 10.3.24.0/30 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 31.31.31.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 32.32.32.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 33.33.33.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 34.34.34.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 35.35.35.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 36.36.36.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 192.170.11.0 [115/35] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 192.170.12.0 [115/35] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 192.170.21.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
i L2 192.170.22.0 [115/25] via 1.1.1.10, 00:02:43, Tunnel11324
You can see that now POP1-C1 reaches POP3 choosing fourth tunnel Tu11324, playing with aoutoroute metric among the 4 four tunnels you can load share (set the same metric) or having a couple of tunnels as preferred then load sharing between these twos or having one of the tunnel as the best.
Remember, what you cannot do is to load share between ONE Tunnel and an IGP path, because once a Tunnel is in place the Headend Router chooses (due to how autoroute works) the Tunnel to reach the Tailend router and everything behind it.
Now let’s consider if this preferred tunnel is really used by switches in POP1 to exit POP1 and to go to POP3:
1.1.1.18 is A3-2 Loopback0’s address.
A1-1#sh run int Lo0 | b int
interface Loopback0
ip address 1.1.1.13 255.255.255.255
ip router isis ACCESS
A1-1#show ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 45, type inter area
Redistributing via isis ACCESS
Last update from 192.168.11.1 on Ethernet0/0, 01:47:37 ago
Routing Descriptor Blocks:
* 192.168.11.1, from 1.1.1.5, 01:47:37 ago, via Ethernet0/0 ==> to POP1-C1
Route metric is 45, traffic share count is 1
A1-1#traceroute
Protocol [ip]:
Target IP address: 1.1.1.18
Source address: 1.1.1.13
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.11.1 1 msec 1 msec 5 msec
2 10.1.13.2 [MPLS: Label 3076 Exp 0] 6 msec 5 msec 4 msec
3 10.0.34.2 [MPLS: Label 4076 Exp 0] 4 msec 5 msec 6 msec
4 10.3.24.1 6 msec 6 msec 6 msec
5 192.170.22.2 5 msec 5 msec 5 msec
traceroute packets go to POP1-C1 and then follow the yellow path.
A1-2#sh run int Lo0 | b int
interface Loopback0
ip address 1.1.1.14 255.255.255.255
ip router isis ACCESS
A1-2#show ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 45, type inter area
Redistributing via isis ACCESS
Last update from 192.168.12.1 on Ethernet0/1, 01:33:04 ago
Routing Descriptor Blocks:
* 192.168.12.1, from 1.1.1.5, 01:33:04 ago, via Ethernet0/1 ==> to POP1-C1
Route metric is 45, traffic share count is 1
A1-2#traceroute
Protocol [ip]:
Target IP address: 1.1.1.18
Source address: 1.1.1.14
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.1 5 msec 5 msec 4 msec
2 10.1.13.2 [MPLS: Label 3076 Exp 0] 5 msec 6 msec 6 msec
3 10.0.34.2 [MPLS: Label 4076 Exp 0] 5 msec 6 msec 5 msec
4 10.3.24.1 5 msec 6 msec 5 msec
5 192.170.22.2 3 msec 5 msec 6 msec
traceroute packets go to POP1-C1 and then follow the yellow path.
Everything is fine, but this is dependent on how I configured isis between the two topology level-2 and level-1, in other words I’m controlling the redistribution from level-2 isis to level-1 isis on POPX-CY routers. Since I configured autoroute on POP1-C1 I’m redistributing the level-2 isis route to 1.1.1.18 with metric 35 (the metric of the tunnel 15 + 20 the metric from POP3-C2 to 1.1.1.18), then both A1-1 and A1-2 sees 1.1.1.18 via POP1-C1 with metric 45 (add 10 to 35 for links between POP1-C1 and A1-X switches)
What I would say is that how traffic really flows over the tunnels depends on how things are designed, in other words POP1-C1 has a Tunnel, but other routers doesn’t know it has this tunnel, if for example A1-1 or A1-2 preferred POP2-C2 to reach 1.1.1.18, Tunnel11324 will be never used:
Here you can see the metric advertised into level-1 topology by POP1-C1 and POP1-C2
POP1-C1#show isis database level-1 POP1-C1.00-00 detail | i 1.1.1.18
Metric: 35 IP-Interarea 1.1.1.18/32
POP1-C1#show isis database level-1 POP1-C2.00-00 detail | i 1.1.1.18
Metric: 50 IP-Interarea 1.1.1.18/32
For example if I modify the metric of the routes redistributed by POP1-C2 setting the metric in the route-map that redistributes level-2 routes into level-1 domain:
POP1-C2#sh run | s r i
………………….
router isis CORE
mpls ldp autoconfig level-2
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2
net 49.0001.0001.0016.00
metric-style wide
log-adjacency-changes
redistribute isis ip level-2 into level-1 route-map LVL2-TO-LVL1
POP1-C2#sh run | s route-map
………………….
route-map LVL2-TO-LVL1 permit 10
match ip address prefix-list ISIS-L2
POP1-C2(config)#route-map LVL2-TO-LVL1 permit 10
POP1-C2(config-route-map)#set metric 20
Now, POP1-C2 is advertising a better route than those advertised by POP1-C1:
POP1-C2#show isis database level-1 POP1-C2.00-00 detail | i 1.1.1.18
Metric: 20 IP-Interarea 1.1.1.18/32
POP1-C2#show isis database level-1 POP1-C1.00-00 detail | i 1.1.1.18
Metric: 35 IP-Interarea 1.1.1.18/32
Checking on A1-1 and A1-2:
A1-1#sh ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 30, type inter area
Redistributing via isis ACCESS
Last update from 192.168.21.1 on Ethernet0/1, 00:06:32 ago
Routing Descriptor Blocks:
* 192.168.21.1, from 1.1.1.6, 00:06:32 ago, via Ethernet0/1
Route metric is 30, traffic share count is 1
A1-1#traceroute
Protocol [ip]:
Target IP address: 1.1.1.18
Source address: 1.1.1.13
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.21.1 5 msec 4 msec 4 msec
2 10.1.23.2 [MPLS: Label 3017 Exp 0] 5 msec 2 msec 5 msec
3 10.0.23.1 [MPLS: Label 2057 Exp 0] 6 msec 5 msec 5 msec
4 10.3.12.1 [MPLS: Label 31057 Exp 0] 5 msec 5 msec 5 msec
5 192.170.12.2 6 msec 5 msec 8 msec
The first hop 192.168.21.1 is POP1-C2, from this router packet goes to 10.1.23.2 (SC3) ==> 10.0.23.1 (SC2) ==> 10.3.12.1 (POP3-C1) ==> 192.170.12.2 (A3-2)
Labels used are those ones imposed by normal MPLS IGP/LDP switching and not by TE Tunnel because we are no more sending the traffic down the tunnel, for example for the first label we see in the trace label 3017:
POP1-C2#show mpls forwarding-table 1.1.1.18
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
12054 1015 1.1.1.18/32 0 Et1/3 10.1.21.1
3017 1.1.1.18/32 0 Et1/2 10.1.23.2
POP1-C2#show ip cef exact-route 1.1.1.13 1.1.1.18
1.1.1.13 -> 1.1.1.18 => label 3017 TAG adj out of Ethernet1/2, addr 10.1.23.2
POP1-C2#show ip cef exact-route 1.1.1.14 1.1.1.18
1.1.1.14 -> 1.1.1.18 => label 1015 TAG adj out of Ethernet1/3, addr 10.1.21.1
A1-2#traceroute
Protocol [ip]:
Target IP address: 1.1.1.18
Source address: 1.1.1.14
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.22.1 5 msec 5 msec 5 msec
2 10.1.21.1 [MPLS: Label 1015 Exp 0] 7 msec 5 msec 5 msec
3 10.0.14.2 [MPLS: Label 4057 Exp 0] 5 msec 6 msec 6 msec
4 10.3.14.1 [MPLS: Label 31057 Exp 0] 5 msec 6 msec 5 msec
5 192.170.12.2 5 msec 5 msec 4 msec
Let’s recap the scenario using the following picture:
Looking at the picture it’s clear that even though we have a Tunnel in the network, others router know nothing about it and traffic flows down the tunnel only if traffic is sent by other router to the router where Tunnel starts and on that router the Tunnel must be the preferred exit interface to the destination of the traffic. How you arrange things to respect this depends on how you deploy your TE solutions, for example you can decide to extend Tunnels up to the Ax-y devices if they support Traffic-Engineering, or you can use static routes.
If your TE solution spans a network made of only one level isis you have another options to make others routers aware of the presence of the tunnel, this option is called “forwarding adjacency”
Forwarding-adjacency is a way to use the TE tunnel as a link in the IGP, then other routers can see this link in the IGP database.
I start from a situation where 4 Tunnels are configured on the Headend POP1-C1 and among these tunnels Tunnel11324 is the preferred one:
POP1-C1#sh run int TU11324 | b interface
interface Tunnel11324
description POP1-C1-to-POP3-C2-n4
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric 15
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name YELLOW
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#show ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 35, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11324, 00:20:36 ago
Routing Descriptor Blocks:
* 1.1.1.10, from 1.1.1.10, 00:20:36 ago, via Tunnel11324
Route metric is 35, traffic share count is 1
What puts Tunnel11324 interface into the routing table of POP1-C1 is the AUTOROUTE feature, but AUTOROUTE is a tool local to the headend. To start using forwarding-adjacency we need to remove autoroute feature (since both features interacts with the SPF database of the IGP they are not compatible)
POP1-C1(config)#int Tu11324
POP1-C1(config-if)#shut
POP1-C1(config-if)#
*Apr 19 09:54:32.617: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11324, changed state to down
*Apr 19 09:54:32.617: %LINK-5-CHANGED: Interface Tunnel11324, changed state to administratively down
POP1-C1(config-if)#no tunnel mpls traffic-eng autoroute announce
POP1-C1(config-if)#no tunnel mpls traffic-eng autoroute metric 15
If you have multiple tunnels on the same router is a good idea to remove autoroute also from all tunnels to avoid unexpected interactions between autoroute and forwarding adjacency.
POP1-C1#sh run int Tu1132 | b interface
interface Tunnel1132
description POP1-C1-to-POP3-C2-n1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x1 mask 0x1
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#sh run int Tu11322 | b interface
interface Tunnel11322
description POP1-C1-to-POP3-C2-n2
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x2 mask 0x2
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP1-C1#sh run int Tu11323 | b interface
interface Tunnel11323
description POP1-C1-to-POP3-C2-n3
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name GREEN
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
To enable forwarding-adjacency it’s enough to activate the feature and to assign an isis metric to the tunnel itself, other routers will se the TE Tunnel as an IGP link with the assigned metric in the IGP database, the two commands are:
POP1-C1(config)#int Tu11324
POP1-C1(config-if)#
isis metric 3 level-2 ==> here I’m assigning an IGP metric of 3 in L2 database of isis for the TE Tunnel path.
tunnel mpls traffic-eng forwarding-adjacency
Then fourth tunnel becomes:
POP1-C1#sh run int Tu11324 | b interface
interface Tunnel11324
description POP1-C1-to-POP3-C2-n4
ip unnumbered Loopback0
shutdown
isis metric 3 level-2
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name YELLOW
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
The first three tunnels are up, but POP1-C1 is not using them to forward traffic to the destination (because I removed autoroute and I have no static routing or policy-based routing making packets to exit one of these tunnels), then in this condition POP1-C1 is using normal IGP routing to reach destinations behind the tunnel tail 1.1.1.10:
POP1-C1#sh ip int br | i Tunnel
Tunnel1132 1.1.1.5 YES TFTP up up
Tunnel11322 1.1.1.5 YES TFTP up up
Tunnel11323 1.1.1.5 YES TFTP up up
Tunnel11324 1.1.1.5 YES TFTP administratively down down
POP1-C1#sh ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 50, type level-2
Redistributing via isis CORE
Last update from 10.1.13.2 on Ethernet1/3, 00:09:11 ago
Routing Descriptor Blocks:
10.1.13.2, from 1.1.1.9, 00:09:11 ago, via Ethernet1/3
Route metric is 50, traffic share count is 1
* 10.1.11.1, from 1.1.1.9, 00:09:11 ago, via Ethernet1/2
Route metric is 50, traffic share count is 1
Let’s see what happens if I activate the tunnel 11324 configured with forwarding adjacency:
POP1-C1(config)#int Tu11324
POP1-C1(config-if)#no shut
*Apr 19 13:36:43.629: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel11324, changed state to up
Tunnel comes up:
POP1-C1#show mpls traffic-eng tunnels Tu11324 brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3171 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 171 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
POP1-C1-to-POP3-C2-n4 1.1.1.10 – Et1/3 up/up
Let’s verify how POP1-C1 reaches for example 1.1.1.18 (A3-2’s Lo0) behind the tunnel tail 1.1.1.10:
POP1-C1#sh ip route 1.1.1.18
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 50, type level-2
Redistributing via isis CORE
Last update from 10.1.13.2 on Ethernet1/3, 00:02:28 ago
Routing Descriptor Blocks:
10.1.13.2, from 1.1.1.9, 00:02:28 ago, via Ethernet1/3
Route metric is 50, traffic share count is 1
* 10.1.11.1, from 1.1.1.9, 00:02:28 ago, via Ethernet1/2
Route metric is 50, traffic share count is 1
Nothing has changed, POP1-C1 is still using normal IGP routing. Why?
POP1-C1#show isis database level-2 POP1-C1.00-00 detail | i IS-Ex
Metric: 10 IS-Extended POP1-C1.04
Metric: 10 IS-Extended POP1-C1.03
Metric: 3 IS-Extended POP3-C2.00
POP1-C1#show isis database level-2 POP1-C1.00-00 verbose | i IS-Ex
Metric: 10 IS-Extended POP1-C1.04
Metric: 10 IS-Extended POP1-C1.03
Metric: 3 IS-Extended POP3-C2.00 (MPLS TE-tunnel)
Extended ISIS TLV are used to describe TE informations.
POP1-C1 sees 3 links in its isis database, the first two are the 2 physical links e1/2 and e1/3 and the third one is the tunnel put into isis database via forwarding-adjacency.
ISIS does a bidirectional check before using a link: isis should be enabled at both side of a link; now a TE Tunnel is an unidirectional path, then ISIS cannot satisfy the bidirectional status of this virtual TE Tunnel link, to confirm this look at the database element describing POP3-C2 into POP1-C1 database:
POP1-C1#show isis database level-2 POP3-C2.00-00 detail | i IS-Ex
Metric: 10 IS-Extended POP3-C2.04
Metric: 10 IS-Extended POP3-C2.03
These are the phsyical links of POP3-C2 but we don’t see a third link atatched to the Tunnel:
POP1-C1#show isis database level-2 POP3-C2.00-00 verbose | i IS-Ex|IP Address
IP Address: 1.1.1.10
Metric: 10 IS-Extended POP3-C2.04
Interface IP Address: 10.3.22.2
Metric: 10 IS-Extended POP3-C2.03
Interface IP Address: 10.3.24.1
To complete the forwarding-adjacency we need a Tunnel going in the opposite direction starting at POP3-C2 and ending on POP1-C1 and this tunnel must be enabled for forwarding adjacency:
POP3-C2#sh run int Tu3211 | b interface
interface Tunnel3211
description POP3-C2-to-POP1-C1
ip unnumbered Loopback0
shutdown
isis metric 15 level-2
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.5
tunnel mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng affinity 0x0 mask 0x0
tunnel mpls traffic-eng path-option 5 explicit name YELLOW
tunnel mpls traffic-eng path-option 10 dynamic
no routing dynamic
POP3-C2#sh run | s explicit-path
ip explicit-path name YELLOW enable
next-address 1.1.1.10
next-address 10.3.24.2
next-address 10.0.34.1
next-address 10.1.13.1
next-address 1.1.1.5
Before actvating this tunnel is worth to check how other routers reaches 1.1.1.18 before forwarding-adjacency is active:
SC3#sh ip route 1.1.1.18 ==> SC3 goes via SC2 or SC4
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 40, type level-2
Redistributing via isis CORE
Last update from 10.0.34.2 on Ethernet0/0, 00:55:49 ago
Routing Descriptor Blocks:
10.0.34.2, from 1.1.1.9, 00:55:49 ago, via Ethernet0/0
Route metric is 40, traffic share count is 1
* 10.0.23.1, from 1.1.1.9, 00:55:49 ago, via Ethernet0/2
Route metric is 40, traffic share count is 1
POP2-C1#traceroute 1.1.1.18 source 1.1.1.7
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 10.2.11.1 [MPLS: Label 1051 Exp 0] 2 msec
10.2.13.2 [MPLS: Label 3018 Exp 0] 6 msec
10.2.11.1 [MPLS: Label 1051 Exp 0] 5 msec
2 10.0.23.1 [MPLS: Label 2057 Exp 0] 5 msec
10.0.12.2 [MPLS: Label 2057 Exp 0] 5 msec
10.0.23.1 [MPLS: Label 2057 Exp 0] 5 msec
3 10.3.12.1 [MPLS: Label 31053 Exp 0] 5 msec 5 msec 5 msec
4 192.170.12.2 5 msec 5 msec 5 msec
Let’s activate the tunnel on POP3-C2:
POP3-C2(config)#int Tu3211
POP3-C2(config-if)#no shut
*Apr 19 14:24:56.990: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3211, changed state to up
POP1-C1#show isis database level-2 POP1-C1.00-00 verbose | i IS-Ex|IP Address
IP Address: 1.1.1.5
Metric: 10 IS-Extended POP1-C1.04
Interface IP Address: 10.1.13.1
Metric: 10 IS-Extended POP1-C1.03
Interface IP Address: 10.1.11.2
Metric: 3 IS-Extended POP3-C2.00 (MPLS TE-tunnel) ==> this shows that the tunnel is in POP1-C1 to POP3-C2 direction
POP1-C1#show isis database level-2 POP3-C2.00-00 verbose | i IS-Ex|IP Address
IP Address: 1.1.1.10
Metric: 10 IS-Extended POP3-C2.04
Interface IP Address: 10.3.22.2
Metric: 10 IS-Extended POP3-C2.03
Interface IP Address: 10.3.24.1
Metric: 3 IS-Extended POP1-C1.00 ==> this shows that POP3-C2 has a tunnel in the opposite direction
POP3-C2#show isis database level-2 POP3-C2.00-00 verbose | i IS-Ex|IP Address
IP Address: 1.1.1.10
Metric: 10 IS-Extended POP3-C2.04
Interface IP Address: 10.3.22.2
Metric: 10 IS-Extended POP3-C2.03
Interface IP Address: 10.3.24.1
Metric: 3 IS-Extended POP1-C1.00 (MPLS TE-tunnel) ==> this shows that the tunnel is in POP3-C2 to POP1-C1 direction
POP3-C2#show isis database level-2 POP1-C1.00-00 verbose | i IS-Ex|IP Address
IP Address: 1.1.1.5
Metric: 10 IS-Extended POP1-C1.04
Interface IP Address: 10.1.13.1
Metric: 10 IS-Extended POP1-C1.03
Interface IP Address: 10.1.11.2
Metric: 3 IS-Extended POP3-C2.00 ==> this shows that POP1-C1 has a tunnel in the opposite direction
POP1-C1#sh ip route 1.1.1.18 ==> this confirms that POP1-C1 is sending traffic down Tunnel11324
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 23, type level-2
Redistributing via isis CORE
Last update from 1.1.1.10 on Tunnel11324, 00:09:47 ago
Routing Descriptor Blocks:
* 1.1.1.10, from 1.1.1.10, 00:09:47 ago, via Tunnel11324
Route metric is 23, traffic share count is 1
Let’s check SC3 and POP2-C1:
SC3#sh ip route 1.1.1.18 ==> SC3 sends traffic destined to 1.1.1.18 to POP1-C1
Routing entry for 1.1.1.18/32
Known via “isis”, distance 115, metric 33, type level-2
Redistributing via isis CORE
Last update from 10.1.13.1 on Ethernet1/3, 00:10:47 ago
Routing Descriptor Blocks:
* 10.1.13.1, from 1.1.1.10, 00:10:47 ago, via Ethernet1/3
Route metric is 33, traffic share count is 1
POP2-C1#traceroute 1.1.1.18 source 1.1.1.7
Type escape sequence to abort.
Tracing the route to 1.1.1.18
VRF info: (vrf in name/id, vrf out name/id)
1 10.2.11.1 [MPLS: Label 1051 Exp 0] 6 msec
10.2.13.2 [MPLS: Label 3018 Exp 0] 5 msec
10.2.11.1 [MPLS: Label 1051 Exp 0] 6 msec
2 10.1.13.1 [MPLS: Label 11014 Exp 0] 6 msec
10.1.11.2 [MPLS: Label 11014 Exp 0] 6 msec
10.1.13.1 [MPLS: Label 11014 Exp 0] 4 msec
3 10.1.13.2 [MPLS: Label 3076 Exp 0] 6 msec 4 msec 5 msec
4 10.0.34.2 [MPLS: Label 4050 Exp 0] 5 msec 6 msec 5 msec
5 10.3.24.1 5 msec 5 msec 6 msec
6 192.170.22.2 5 msec 7 msec 5 msec
POP2-C1 loads balance between SC1 and SC3, then these twos send traffic to POP1-C1 that sends traffic down Tunnel11324 (hop 3,4,5 are the Explicit Route Object defined by this tunnel)
To recap: The very big difference between AUTOROUTE and FORWARDING-ADJACENCY is that the first one is valid only locally at the Headend, other routers are not aware of the existence of tunnel on other routers, then if you want to send traffic to the router where the tunnel is configured you must adjust routing info on all other routers, with the second one, the TE Tunnel path is used as an IGP link in IGP database then this information is distributed by IGP on all other routers, in this way if you use a low metric on the tunnel interface you can attract traffic (for destinations behind the tunnel tail) on the Headend Router, but remember to be effective forwarding-adjacency must have bidirectional tunnels between the Headend and Tailend routes so that ISIS can satisfy its bidirectional check. This of course comes to scalability of your TE solution, for example it’s easy to use forwarding-adjacency when your TE solutions is deployed as a full mesh of TE tunnels between all the routers. Another thing to remeber is that forwarding-adjacency is valid only on single level domain (only level-2 or only level-1 domain, this because routers cannot have an idea of the topology of routers inside different levels.)
To finish this section, here you can read all the method you have to forward traffic down a tunnel:
1) Policy-based routing (other routers know nothing about the tunnels configured on different routers)
2) Static routing (other routers know nothing about the tunnels configured on different routers)
3) Autoroute (other routers know nothing about the tunnels configured on different routers)
4) Forwarding-adjacency (other routers knows about the tunnels configured on different routers, use it with bidirectional Tunnels and only on single level domains)
This completes my first short excursion on TE matter, many other concepts belongs to MPLS-TE technology (Fast Reroute, Tunnel Reoptimization, Tactical TE deployment, Strategic TE deployment…) most important you need an overall plan about how to use MPLS-TE once you know how an MPLS-TE Tunnel works.