IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will look at the link "affinity" that can be used to selectively include or exclude link(s) from being in the transit path from the TE head end to the tail end. The idea of the link affinity or link color is to label an interface with a set of values that could be mapped to SLA or service level agreement. Blue could be bulk traffic, Green could be transactional data, Red could be low latency and Orange could be high bandwidth. The idea is to use the "affinity" or attribute flags at the interface level so RSVP would know if that link is or is not to be used for TE forwarding.
For those familiar with the ACL or Access Control Lists, the idea with the "anding" values is to use bits in the "wildcard" mask to directly map to the prefix to determine the level of match. Where a "0" means "This matters" or "must match" and the "1" means "this doesn't matter" or "I don't care". TE uses the reverse in it's logic, "1" means to match and "0" means to disregard. So when the TE tunnel is configured, if no "affinity" values are configured at the tunnel level and "attribute flags" are configured at the interface level, the tunnel will fail to come up.
The Affinity colors on the individual links directly correlate to a specific attribute flag configured at the interface level, specifying an affinity match value is required in our topology to allow RSVP to signal an end to end path.
R1
interface GigabitEthernet1.111
mpls traffic-eng attribute-flags 0x6
!
interface GigabitEthernet1.115
mpls traffic-eng attribute-flags 0x1011
R3
interface GigabitEthernet1.34
mpls traffic-eng attribute-flags 0x1011
!
interface GigabitEthernet1.143
mpls traffic-eng attribute-flags 0x110
R4
interface GigabitEthernet1.34
mpls traffic-eng attribute-flags 0x1011
!
interface GigabitEthernet1.154
mpls traffic-eng attribute-flags 0x1111
XR1
mpls traffic-eng
interface GigabitEthernet0/0/0/0.111
attribute-flags 0x110
!
interface GigabitEthernet0/0/0/0.1114
attribute-flags 0x101
XR4
mpls traffic-eng
interface GigabitEthernet0/0/0/0.143
attribute-flags 0x110
!
interface GigabitEthernet0/0/0/0.1114
attribute-flags 0x101
!
interface GigabitEthernet0/0/0/0.1415
attribute-flags 0x1111
XR5
mpls traffic-eng
interface GigabitEthernet0/0/0/0.115
attribute-flags 0x1011
!
interface GigabitEthernet0/0/0/0.154
attribute-flags 0x1111
!
interface GigabitEthernet0/0/0/0.1415
attribute-flags 0x1111
R3
interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 192.168.1.1
tunnel mpls traffic-eng path-option 1 dynamic
The result:
TE-PCALC: 192.168.1.3_364->192.168.1.1_1 {7}: Path Request Info
Flags: METRIC_TE
IP explicit-path: None (dynamic)
bw 0, min_bw 0, metric: 0
setup_pri 7, hold_pri 7
affinity_bits 0x0, affinity_mask 0xFFFF
TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Area (ospf 1 area 0) Path Lookup begin
TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Get path: Failed to find a path to destination
TE-PCALC-PATH: 192.168.1.3_364->192.168.1.1_1 {7}: Area (ospf 1 area 0) Path Lookup end: path not found
TE-PCALC-API: 192.168.1.3_364->192.168.1.1_1 {7}: P2P LSP Path Lookup result: failed
The problem is that no affinity values were set, and every path from R3 to R1 has some attribute flag value configured, so when the RSVP PATH message tries to begin, it immediately fails due to the lack of TE tunnel affinity configuration.
R3#sh mpls traffic-eng tunnels tunnel 1
Name: R3_t1 (Tunnel1) Destination: 192.168.1.1
Status:
Admin: up Oper: down Path: not valid Signalling: Down
The operational state, Path and Signaling are all down or not valid.
To fix this we need to configure R3s TE Tunnel 1 with an appropriate affinity value and mask combination that will allow an end to end match to be made, this can be a combination of yes to Green and no to Red along the same path. We'll take a look at how that works later. For now, a simple affinity value and mask config at the TE tunnel level will suffice. Once configured, we'll have to flap the tunnel interface to force an RSVP PATH message
interface Tunnel1
tunnel mpls traffic-eng affinity 0x0001 mask 0x0001
TE-PCALC-API: 192.168.1.3_394->192.168.1.1_1 {7}: P2P LSP Path Lookup called
TE-PCALC: 192.168.1.3_394->192.168.1.1_1 {7}: Path Request Info
Flags: METRIC_TE
IP explicit-path: None (dynamic)
bw 0, min_bw 0, metric: 0
setup_pri 7, hold_pri 7
affinity_bits 0x1, affinity_mask 0x1
TE-PCALC-PATH: 192.168.1.3_394->192.168.1.1_1 {7}: Area (ospf 1 area 0) Path Lookup begin
TE-PCALC-PATH:Path from 192.168.1.3 -> 192.168.1.1:
10.1.15.1->0.0.0.0 (admin_weight=3):
10.1.15.15->0.0.0.0 (admin_weight=3):
10.15.4.15->0.0.0.0 (admin_weight=2):
10.15.4.4->0.0.0.0 (admin_weight=2):
10.3.4.4->0.0.0.0 (admin_weight=1):
10.3.4.3->0.0.0.0 (admin_weight=1):
num_hops 7, accumulated_aw 3, min_bw 0
TE-PCALC-PATH: 192.168.1.3_394->192.168.1.1_1 {7}: Area (ospf 1 area 0) Path Lookup end: path found
TE-PCALC-API: 192.168.1.3_394->192.168.1.1_1 {7}: P2P LSP Path Lookup result: success
Calling ext path_addmodify arginfo: 0x7EFF4BF8B540, avg: 0, peak: N/A, burst: 0x3E8
mtu: N/A, qos: N/A,hint: 0x1600018A, new: TRUE, sub_lsp: 0x7EFF4C446020
*Jan 24 22:53:14.446: %MPLS_TE-5-TUN: Tun1: installed LSP 1_394 (popt 1) for nil, got 1st feasible path opt
RSVP: session 192.168.1.1_1[192.168.1.3] (7): Received Resv message from 10.3.4.4 (on GigabitEthernet1.34)
RSVP: 192.168.1.3_394->192.168.1.1_1[Src] {7}: Successfully parsed Resv message from 10.3.4.4 (on GigabitEthernet1.34)
RSVP: 192.168.1.3_394->192.168.1.1_1[Src] {7}: reservation not found--new one
*Jan 24 22:53:14.564: %MPLS_TE-5-LSP: LSP 192.168.1.3 1_394: UP
RSVP-RESV: Admitting new reservation: 7EFF4BFFC110
RSVP-RESV: reservation (RSB 0x7EFF4BFFC110) was installed on GigabitEthernet1.34
*Jan 24 22:53:14.564: %MPLS_TE-5-TUN: Tun1: LSP path change 1_394 for nil, normal
*Jan 24 22:53:14.568: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R3#sh mpls traffic-eng tunnels tunnel 1 | sec Affinity
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x1/0x1
RSVP
10.3.4.4 10.15.4.4 10.15.4.15 10.1.15.15
10.1.15.1 192.168.1.1
By setting an affinity value that is matchable at the interface level, the RSVP PATH messages make it all the way down to R1 and the RSVP RESV messages make it all the way back to R3.
R3#sh mpls traffic-eng tunnels tunnel 1
Name: R3_t1 (Tunnel1) Destination: 192.168.1.1
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 3)
R3#sh ip rsvp reservation detail filter session-type 7 tunnel-id 1 | b Label
Label: 23 (outgoing)
We can see that label 23 was assigned via RSVP-TE.
R3#sh ip cef 192.168.1.1 detail
192.168.1.1/32, epoch 2, flags [attached]
local label info: global/32
3 RR sources [non-eos indirection, heavily shared]
attached to Tunnel1
Local label 32 was assigned and we can use the MPLS forwarding table to see the detailed output for that.
R3#sh mpls forwarding-table labels 32 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 Pop Label 192.168.1.1/32 0 Tu1 point2point
MAC/Encaps=18/22, MRU=1500, Label Stack{23}, via Gi1.34
000C2924DCA2000C29062644810000228847 00017000
No output feature configured
Label 23 is the label stack to get us to our next hop of R4.
R3#traceroute 192.168.1.1 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.3.4.4 [MPLS: Label 23 Exp 0] 5 msec 3 msec 3 msec
2 10.15.4.15 [MPLS: Label 24000 Exp 0] 20 msec 7 msec 8 msec
3 10.1.15.1 7 msec * 8 msec
And the traceroute proves that we are taking the appropriate path. Let's test the end to end reachability from R8 to R13.
R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 13.13.13.13
VRF info: (vrf in name/id, vrf out name/id)
1 83.0.0.3 3 msec 1 msec 1 msec
2 10.3.4.4 [MPLS: Labels 23/28 Exp 0] 8 msec 7 msec 7 msec
3 10.15.4.15 [MPLS: Labels 24000/28 Exp 0] 28 msec 31 msec 31 msec
4 131.0.0.1 [MPLS: Label 28 Exp 0] 17 msec 15 msec 15 msec
5 131.0.0.13 20 msec * 11 msec
As you can see, we take the TE path.
We can also tell TSVP-TE via affinity bits to not use a path that has a certain color. For instance we could tell RSVP to avoid paths where the color Orange is applied.
interface Tunnel1
tunnel mpls traffic-eng affinity 0x0 mask 0x8
R3#sh mpls traffic-eng tunnels tunnel 1
Name: R3_t1 (Tunnel1) Destination: 192.168.1.1
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 3)
R3#sh mpls traffic-eng tunnels tunnel 1 | b RSVP
RSVP Signalling Info:
Src 192.168.1.3, Dst 192.168.1.1, Tun_Id 1, Tun_Instance 396
RSVP Path Info:
My Address: 10.14.3.3
Explicit Route: 10.14.3.14 10.11.14.14 10.11.14.11 10.1.11.11
10.1.11.1 192.168.1.1
You can see that the path changed to avoid any links where the color Orange was applied.
R3#sh ip cef 192.168.1.1 detail
192.168.1.1/32, epoch 2, flags [attached]
local label info: global/32
3 RR sources [non-eos indirection, heavily shared]
attached to Tunnel1
R3#sh mpls forwarding-table labels 32 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 Pop Label 192.168.1.1/32 0 Tu1 point2point
MAC/Encaps=18/22, MRU=1500, Label Stack{24001}, via Gi1.143
000C29769933000C290626448100008F8847 05DC1000
No output feature configured
You can see that a new label, 24001 has been issued with a next hop of XR4.
R3#traceroute 192.168.1.1 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.14.3.14 [MPLS: Label 24001 Exp 0] 6 msec 5 msec 4 msec
2 10.11.14.11 [MPLS: Label 24001 Exp 0] 6 msec 6 msec 6 msec
3 10.1.11.1 8 msec * 10 msec
The test is to see what path we take in the network now that we are avoiding the Orange links.
R8#traceroute vrf BGP 13.13.13.13 source 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 13.13.13.13
VRF info: (vrf in name/id, vrf out name/id)
1 83.0.0.3 3 msec 1 msec 1 msec
2 10.14.3.14 [MPLS: Labels 24001/28 Exp 0] 7 msec 10 msec 7 msec
3 10.11.14.11 [MPLS: Labels 24001/28 Exp 0] 27 msec 31 msec 65 msec
4 131.0.0.1 [MPLS: Label 28 Exp 0] 11 msec 7 msec 7 msec
5 131.0.0.13 7 msec * 9 msec
It is working as expected.
There are several other matching variations we could test out. I will leave those for upcoming posts.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment