Rob Riker/ Simplified Networking: mpls l3 vpn

Showing posts with label mpls l3 vpn. Show all posts

Wednesday, December 5, 2018

CCIE SPv4 MPLS Inter AS Option A BGP VRF Aware Traffic Engineering - AS Path

In this post we'll be taking a look at AS Path prepending to influence the path taken by traffic as it is coming back to the originator. If you want to influence or engineer which way return traffic will enter your network, AS Path prepending is the ideal way to accomplish this.

IOSv9#traceroute vrf BGP 1.1.1.1 source lo0 num

Type escape sequence to abort.

Tracing the route to 1.1.1.1

VRF info: (vrf in name/id, vrf out name/id)

1 20.9.10.10 20 msec 5 msec 4 msec

2 10.10.10.100 [MPLS: Labels 24002/37 Exp 0] 55 msec 21 msec 20 msec

3 20.11.14.11 [MPLS: Label 37 Exp 0] 26 msec 10 msec 11 msec

4 20.11.14.14 28 msec 20 msec 17 msec

5 10.3.14.3 [MPLS: Labels 18/33 Exp 0] 73 msec 46 msec 44 msec

6 10.13.3.13 [MPLS: Labels 24003/33 Exp 0] 63 msec 44 msec 49 msec

7 20.1.1.1 [MPLS: Label 33 Exp 0] 55 msec 94 msec 46 msec

8 20.1.1.10 56 msec * 109 msec

We'll test this on IOSv6 towards IOSv1 and we see that we use the CSR11/XRzv4 Inter AS connection to reach IOSv1.

CSR11#sh bgp vrf BGP

BGP table version is 78, local router ID is 2.2.2.11

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:20 (default for vrf BGP)

*> 1.1.1.1/32 20.11.14.14 0 100 65001 i

*> 2.2.2.2/32 20.11.14.14 0 100 65002 i

*> 3.3.3.3/32 20.11.14.14 0 100 65003 i

*>i 7.7.7.7/32 2.2.2.12 0 100 0 65007 i

*>i 9.9.9.9/32 2.2.2.10 0 100 0 65009 i

*> 10.10.10.10/32 20.10.11.10 0 0 65010 i

*> 172.16.0.0/24 20.11.14.14 0 100 65001 i

*> 172.16.1.0/24 20.11.14.14 0 100 65001 i

*> 172.16.2.0/24 20.11.14.14 0 100 65001 i

Checking CSR11 BGP table we see that the path should ride over the CSR11/XRv4 path as the traceroute shows. Now we need to configure XRv4 to tell CSR11 that this path is now less preferred by adding AS Path hops to the AS Path list that XRv4 is advertising to CSR11. This is done by creating an RPL and prepending AS 100 three times to the RPL. The RPL is then applied outbound on the CSR11/XRv4 eBGP peering under the VRF.

route-policy RPL_AS_PATH

prepend as-path 100 3

end-policy

router bgp 100

vrf BGP

neighbor 20.11.14.11

remote-as 200

address-family ipv4 unicast

route-policy PASS in

route-policy RPL_AS_PATH out

CSR11#show bgp vrf BGP

BGP table version is 48, local router ID is 2.2.2.11

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:20 (default for vrf BGP)

*>i 1.1.1.1/32 2.2.2.14 0 100 0 100 65001 i

* 20.11.14.14 0 100 100 100 100 65001 i

*>i 2.2.2.2/32 2.2.2.14 0 100 0 100 65002 i

* 20.11.14.14 0 100 100 100 100 65002 i

*>i 3.3.3.3/32 2.2.2.14 0 100 0 100 65003 i

* 20.11.14.14 0 100 100 100 100 65003 i

*>i 7.7.7.7/32 2.2.2.12 0 100 0 65007 i

*>i 9.9.9.9/32 2.2.2.10 0 100 0 65009 i

*> 10.10.10.10/32 20.10.11.10 0 0 65010 i

*>i 172.16.0.0/24 2.2.2.14 0 100 0 100 65001 i

* 20.11.14.14 0 100 100 100 100 65001 i

Network Next Hop Metric LocPrf Weight Path

*>i 172.16.1.0/24 2.2.2.14 0 100 0 100 65001 i

* 20.11.14.14 0 100 100 100 100 65001 i

*>i 172.16.2.0/24 2.2.2.14 0 100 0 100 65001 i

* 20.11.14.14 0 100 100 100 100 65001 i

After modifying the AS Path length, we see that any routes learned from XRv4 now show 4 100's in the AS Path list. Which proves that the AS Path modification was successfully configured and applied to CSR11's BGP table.

IOSv9#traceroute vrf BGP 1.1.1.1 source lo0 num

Type escape sequence to abort.

Tracing the route to 1.1.1.1

VRF info: (vrf in name/id, vrf out name/id)

1 20.9.10.10 37 msec 11 msec 5 msec

2 10.10.10.100 [MPLS: Labels 24010/24018 Exp 0] 183 msec 122 msec 39 msec

3 10.11.10.11 [MPLS: Labels 31/24018 Exp 0] 35 msec 32 msec 27 msec

4 10.11.14.14 [MPLS: Labels 16/24018 Exp 0] 26 msec 50 msec 24 msec

5 10.9.14.9 [MPLS: Label 24018 Exp 0] 81 msec 22 msec 29 msec

6 20.6.9.6 141 msec 30 msec 21 msec

7 10.6.15.15 [MPLS: Labels 24003/33 Exp 0] 53 msec 39 msec 96 msec

8 10.11.15.11 [MPLS: Labels 24002/33 Exp 0] 79 msec 53 msec 63 msec

9 10.3.11.3 [MPLS: Labels 18/33 Exp 0] 51 msec 71 msec 107 msec

10 10.13.3.13 [MPLS: Labels 24003/33 Exp 0] 148 msec 78 msec 51 msec

11 20.1.1.1 [MPLS: Label 33 Exp 0] 72 msec 41 msec 50 msec

12 20.1.1.10 61 msec * 61 msec

The traceroute also shows that the new path goes through CSR6 and XRv9.

We'll configure AS Path Prepending on IOS now on the CSR.

IOSV1#traceroute vrf BGP 9.9.9.9 source loopback 0 num

Type escape sequence to abort.

Tracing the route to 9.9.9.9

VRF info: (vrf in name/id, vrf out name/id)

1 20.1.1.1 12 msec 51 msec 5 msec

2 10.1.13.13 [MPLS: Labels 24006/83 Exp 0] 28 msec 207 msec 26 msec

3 10.13.3.3 [MPLS: Labels 28/83 Exp 0] 24 msec 21 msec 23 msec

4 10.3.11.11 [MPLS: Labels 24009/83 Exp 0] 31 msec 24 msec 23 msec

5 20.2.14.2 [MPLS: Label 83 Exp 0] 25 msec 24 msec 18 msec

6 20.2.14.14 55 msec 21 msec 17 msec

7 10.11.14.11 [MPLS: Labels 17/25 Exp 0] 43 msec 59 msec 50 msec

8 10.11.10.10 [MPLS: Labels 24000/25 Exp 0] 38 msec 30 msec 62 msec

9 20.9.10.10 [MPLS: Label 25 Exp 0] 42 msec 35 msec 49 msec

10 20.9.10.9 49 msec * 157 msec

We execute a traceroute on IOSv1 towards IOSv9 and see the Inter AS path going between CSR2 and CSR14. This also let's us prove that AS Path prepending affects only inbound traffic. Since traffic leaving out IOSv1 towards IOSv9 does not take the CSR6/XRv9 path.

CSR2#sh bgp vrf BGP

BGP table version is 73, local router ID is 1.1.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:20 (default for vrf BGP)

*>i 1.1.1.1/32 1.1.1.1 0 100 0 65001 i

*>i 2.2.2.2/32 1.1.1.4 0 100 0 65002 i

*>i 3.3.3.3/32 1.1.1.14 0 100 0 65003 i

*> 7.7.7.7/32 20.2.14.14 0 200 65007 i

*> 9.9.9.9/32 20.2.14.14 0 200 65009 i

*> 10.10.10.10/32 20.2.14.14 0 200 65010 i

*>i 172.16.0.0/24 1.1.1.1 0 100 0 65001 i

*>i 172.16.1.0/24 1.1.1.1 0 100 0 65001 i

*>i 172.16.2.0/24 1.1.1.1 0 100 0 65001 i

We check CSR2s table to prove nothing has been modified yet. We configure a route-map setting the AS Path of 200 three times. The route-map is then applied to the neighbor outbound.

route-map RM_AS_PATH permit 10

set as-path prepend 200 200 200

router bgp 200

address-family ipv4 vrf BGP

neighbor 20.2.14.2 remote-as 100

neighbor 20.2.14.2 activate

neighbor 20.2.14.2 route-map RM_AS_PATH out

CSR2(config-router-af)#do sh bgp vrf BGP

BGP table version is 67, local router ID is 1.1.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:20 (default for vrf BGP)

*>i 1.1.1.1/32 1.1.1.1 0 100 0 65001 i

*>i 2.2.2.2/32 1.1.1.4 0 100 0 65002 i

*>i 3.3.3.3/32 1.1.1.14 0 100 0 65003 i

*>i 7.7.7.7/32 1.1.1.6 0 100 0 200 65007 i

* 20.2.14.14 0 200 200 200 200 65007 i

*>i 9.9.9.9/32 1.1.1.6 0 100 0 200 65009 i

* 20.2.14.14 0 200 200 200 200 65009 i

*>i 10.10.10.10/32 1.1.1.6 0 100 0 200 65010 i

* 20.2.14.14 0 200 200 200 200 65010 i

*>i 172.16.0.0/24 1.1.1.1 0 100 0 65001 i

*>i 172.16.1.0/24 1.1.1.1 0 100 0 65001 i

Network Next Hop Metric LocPrf Weight Path

*>i 172.16.2.0/24 1.1.1.1 0 100 0 65001 i

After executing a soft route-refresh on CSR14 we see that the AS Path list on CSR2 shows the added AS hops in the AS Path list.

IOSV1#traceroute vrf BGP 9.9.9.9 source loopback 0 num

Type escape sequence to abort.

Tracing the route to 9.9.9.9

VRF info: (vrf in name/id, vrf out name/id)

1 20.1.1.1 29 msec 5 msec 3 msec

2 10.1.13.13 [MPLS: Labels 24008/42 Exp 0] 52 msec 31 msec 46 msec

3 10.13.3.3 [MPLS: Labels 20/42 Exp 0] 31 msec 38 msec 31 msec

4 10.3.11.11 [MPLS: Labels 24006/42 Exp 0] 87 msec 50 msec 92 msec

5 10.11.15.15 [MPLS: Labels 24002/42 Exp 0] 86 msec 41 msec 35 msec

6 20.6.9.6 [MPLS: Label 42 Exp 0] 41 msec 46 msec 28 msec

7 20.6.9.9 45 msec 30 msec 81 msec

8 10.9.14.14 [MPLS: Labels 24/25 Exp 0] 59 msec 84 msec 71 msec

9 10.11.14.11 [MPLS: Labels 17/25 Exp 0] 51 msec 48 msec 56 msec

10 10.11.10.10 [MPLS: Labels 24000/25 Exp 0] 72 msec 60 msec 49 msec

11 20.9.10.10 [MPLS: Label 25 Exp 0] 44 msec 39 msec 51 msec

12 20.9.10.9 88 msec * 41 msec

We retest and see traffic going over the CSR6 path as indicated in CSR2s BGP table pointing towards 1.1.1.6 as the next hop.

Thanks for stopping by!

Rob Riker, CCIE #50693

Sunday, December 2, 2018

CCIE SPv4 MPLS Inter AS Option A BGP VRF Aware Traffic Engineering - Weight

In this post we will take a look at the BGP attribute Weight. It's Cisco Proprietary and for the most part, I am not a fan of using the command. I have only used it a couple times in production to influence traffic locally, which is the only thing this command can do. The reason it wasn't the first topic is because Weight is automatically tied to any locally originated routes, 32768 specifically which can be modified. We'll modify the weight on a specific network statement to see how it gets applied. Weight can also be used to steer traffic traversing through a router out a given neighbor as well, applied inbound with a route-map. This is the common use for it but since it can also be applied to a network statement to change the default weight, that's what we'll take a look at here.

router bgp 65001
address-family ipv4 vrf BGP
network 1.1.1.1 mask 255.255.255.255
network 172.16.0.0 mask 255.255.255.0
network 172.16.1.0 mask 255.255.255.0
network 172.16.2.0 mask 255.255.255.0

First thing we need to do is add a couple loopbacks, place them in the VRF and then use network statements to advertise them.

IOSV1(config-router-af)#do sh bgp vrf BGP
BGP table version is 18, local router ID is 100.1.1.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf BGP)
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 20.1.1.1 0 100 65003 i
*> 7.7.7.7/32 20.1.1.1 0 100 200 65007 i
*> 9.9.9.9/32 20.1.1.1 0 100 200 65009 i
*> 10.10.10.10/32 20.1.1.1 0 100 200 65010 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 32768 i

We can see the new routes being advertised into BGP.

route-map RM_WGT_40000 permit 10
set weight 40000
!
router bgp 65001
address-family ipv4 vrf BGP
network 172.16.2.0 mask 255.255.255.0 route-map RM_WGT_40000

To change the weight, a route-map needs to set the weight with a set command. Then the route map is applied to the network statement.

IOSV1(config-router-af)#do sh bgp vrf BGP
BGP table version is 19, local router ID is 100.1.1.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf BGP)
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 40000 i

Now that the route-map has been applied and BGP was re-synced, we can see the weight applied to the network we advertised.

The other way to apply Weight to directly to the neighbor via the "weight" command or applying a route-map to the neighbor inbound.

IOSv2(config-if)#do sh bgp vrf BGP
BGP table version is 10, local router ID is 100.2.4.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf BGP)
* 1.1.1.1/32 20.2.4.4 0 100 65001 i
*> 20.1.2.1 0 100 65001 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
* 3.3.3.3/32 20.2.4.4 0 100 65003 i
*> 20.1.2.1 0 100 65003 i
* 7.7.7.7/32 20.2.4.4 0 100 200 65007 i
*> 20.1.2.1 0 100 200 65007 i
* 9.9.9.9/32 20.2.4.4 0 100 200 65009 i
*> 20.1.2.1 0 100 200 65009 i
* 10.10.10.10/32 20.2.4.4 0 100 200 65010 i
*> 20.1.2.1 0 100 200 65010 i
* 172.16.0.0/24 20.2.4.4 0 100 65001 i
*> 20.1.2.1 0 100 65001 i
Network Next Hop Metric LocPrf Weight Path
* 172.16.1.0/24 20.2.4.4 0 100 65001 i
*> 20.1.2.1 0 100 65001 i
* 172.16.2.0/24 20.2.4.4 0 100 65001 i

*> 20.1.2.1 0 100 65001 i

router bgp 65002
bgp log-neighbor-changes
!
address-family ipv4 vrf BGP
network 2.2.2.2 mask 255.255.255.255
neighbor 20.1.2.1 remote-as 100
neighbor 20.1.2.1 activate
neighbor 20.1.2.1 weight 100
neighbor 20.2.4.4 remote-as 100
neighbor 20.2.4.4 activate
neighbor 20.2.4.4 weight 400

exit-address-family

IOSv2(config-router-af)#do sh bgp vrf BGP
BGP table version is 26, local router ID is 100.2.4.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf BGP)
*> 1.1.1.1/32 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 20.2.4.4 400 100 65003 i
* 20.1.2.1 100 100 65003 i
*> 7.7.7.7/32 20.2.4.4 400 100 200 65007 i
* 20.1.2.1 100 100 200 65007 i
*> 9.9.9.9/32 20.2.4.4 400 100 200 65009 i
* 20.1.2.1 100 100 200 65009 i
*> 10.10.10.10/32 20.2.4.4 400 100 200 65010 i
* 20.1.2.1 100 100 200 65010 i
*> 172.16.0.0/24 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
*> 172.16.2.0/24 20.2.4.4 400 100 65001 i

* 20.1.2.1 100 100 65001 i

We can selectively change the weight for a specific prefix and set the weight for all other routes to different weight values.

ip prefix-list R9 seq 5 permit 9.9.9.9/32
!
route-map RM_WGHT permit 10
match ip address prefix-list R9
set weight 900
route-map RM_WGHT permit 20

set weight 100
!
router bgp 65002
bgp log-neighbor-changes
!
address-family ipv4 vrf BGP

neighbor 20.1.2.1 route-map RM_WGHT in

IOSv2(config-route-map)#do sh bgp vrf BGP
BGP table version is 27, local router ID is 100.2.4.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf BGP)
*> 1.1.1.1/32 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 20.2.4.4 400 100 65003 i
* 20.1.2.1 100 100 65003 i
*> 7.7.7.7/32 20.2.4.4 400 100 200 65007 i
* 20.1.2.1 100 100 200 65007 i
* 9.9.9.9/32 20.2.4.4 400 100 200 65009 i
*> 20.1.2.1 900 100 200 65009 i
*> 10.10.10.10/32 20.2.4.4 400 100 200 65010 i
* 20.1.2.1 100 100 200 65010 i
*> 172.16.0.0/24 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 20.2.4.4 400 100 65001 i
* 20.1.2.1 100 100 65001 i
*> 172.16.2.0/24 20.2.4.4 400 100 65001 i

* 20.1.2.1 100 100 65001 i

With the route-map applied, we can see that the prefix 9.9.9.9/32 has a weight of 900 pointing towards CSR1. Let's test this out via traceroute to see if the paths do take the appropriate paths.

IOSv2#traceroute vrf BGP 7.7.7.7 so lo0 num
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
1 20.2.4.4 14 msec 4 msec 5 msec
2 10.4.12.12 [MPLS: Labels 24009/82 Exp 0] 24 msec 27 msec 25 msec
3 10.5.12.5 [MPLS: Labels 16/82 Exp 0] 21 msec 23 msec 23 msec
4 10.5.11.11 [MPLS: Labels 24009/82 Exp 0] 26 msec 70 msec 53 msec
5 20.2.14.2 [MPLS: Label 82 Exp 0] 24 msec 17 msec 20 msec
6 20.2.14.14 28 msec 26 msec 43 msec
7 10.11.14.11 [MPLS: Labels 27/38 Exp 0] 61 msec 52 msec 74 msec
8 10.11.10.10 [MPLS: Labels 24007/38 Exp 0] 52 msec 56 msec 50 msec
9 20.7.12.12 [MPLS: Label 38 Exp 0] 60 msec 46 msec 39 msec

10 20.7.12.7 76 msec * 79 msec

IOSv2#traceroute vrf BGP 9.9.9.9 so lo0 num
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
1 20.1.2.1 13 msec 3 msec 3 msec
2 10.1.13.13 [MPLS: Labels 24006/83 Exp 0] 33 msec 23 msec 31 msec
3 10.13.3.3 [MPLS: Labels 28/83 Exp 0] 44 msec 37 msec 35 msec
4 10.3.11.11 [MPLS: Labels 24009/83 Exp 0] 25 msec 34 msec 22 msec
5 20.2.14.2 [MPLS: Label 83 Exp 0] 23 msec 23 msec 21 msec
6 20.2.14.14 27 msec 30 msec 36 msec
7 10.11.14.11 [MPLS: Labels 17/25 Exp 0] 48 msec 44 msec 48 msec
8 10.11.10.10 [MPLS: Labels 24000/25 Exp 0] 119 msec 71 msec 47 msec
9 20.9.10.10 [MPLS: Label 25 Exp 0] 70 msec 68 msec 59 msec

10 20.9.10.9 54 msec * 123 msec

We can see that the path towards 7.7.7.7 goes via CSR4 and 9.9.9.9 goes via CSR1.

Thanks for stopping by!
Rob Riker, CCIE #50693

Thursday, May 10, 2018

Segment Routing with RSVP-Traffic Engineering Tunnels

In the previous post we discussed setting up SR.

SR is now running but its relying on IGP for the shortest path through the SP core. RSVP-TE is used to choose the best route and not necessarily the shortest path. We'll pretend that the connections between XR1 and XR2, XR3 and XR4 are 10 Gbps connections, the rest of the network is 40 Gbps. The goal is to build a TE tunnel that will take the path XR1 > XR5 > XR6 > XR2 > XR3 > XR7 > XR8 > XR4, which will effectively bypass the slower links. There will also be a backup path option that will be able to take the direct XR1 > XR2 > XR3 > XR4 path.

The first thing that needs to be done is enabling MPLS Traffic Engineering, RSVP and enabling OSPF to support MPLS TE for area 0.

XR1 - XR8
router ospf 1
area 0
mpls traffic-eng
!
mpls traffic-eng router-id Loopback0

XR1
rsvp
interface GigabitEthernet0/0/0/0.112
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.115
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.112
!
interface GigabitEthernet0/0/0/0.115

XR2
rsvp
interface GigabitEthernet0/0/0/0.112
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.123
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.126
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.112
!
interface GigabitEthernet0/0/0/0.123
!
interface GigabitEthernet0/0/0/0.126

XR3
rsvp
interface GigabitEthernet0/0/0/0.123
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.134
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.137
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.123
!
interface GigabitEthernet0/0/0/0.134
!
interface GigabitEthernet0/0/0/0.137

XR4
rsvp
interface GigabitEthernet0/0/0/0.134
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.148
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.134
!
interface GigabitEthernet0/0/0/0.148

XR5
rsvp
interface GigabitEthernet0/0/0/0.115
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.156
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.115
!
interface GigabitEthernet0/0/0/0.156

XR6
rsvp
interface GigabitEthernet0/0/0/0.126
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.156
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.167
bandwidth 750000
!
!
mpls traffic-eng
!
interface GigabitEthernet0/0/0/0.126
!
interface GigabitEthernet0/0/0/0.156
!
interface GigabitEthernet0/0/0/0.167

XR7
rsvp
interface GigabitEthernet0/0/0/0.137
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.167
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.178
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.137
!
interface GigabitEthernet0/0/0/0.167
!
interface GigabitEthernet0/0/0/0.178

XR8
rsvp
interface GigabitEthernet0/0/0/0.148
bandwidth 750000
!
interface GigabitEthernet0/0/0/0.178
bandwidth 750000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0.148
!
interface GigabitEthernet0/0/0/0.178

Now that we have built the TE topology, we can build the unidirectional tunnel from XR1 to XR4 via the path we laid out from above, there should also be another path option that follows the IGP path. The TE tunnel should advertise the TE tunnel as an IGP route.

XR1
explicit-path name SR_TE
index 1 next-address strict ipv4 unicast 192.0.2.25
index 2 next-address strict ipv4 unicast 192.0.2.26
index 3 next-address strict ipv4 unicast 192.0.2.22
index 4 next-address strict ipv4 unicast 192.0.2.23
index 5 next-address strict ipv4 unicast 192.0.2.27
index 6 next-address strict ipv4 unicast 192.0.2.28
index 7 next-address strict ipv4 unicast 192.0.2.24
!
interface tunnel-te1
ipv4 unnumbered Loopback0
autoroute announce
!
destination 192.0.2.24
path-option 5 explicit name SR_TE segment-routing
path-option 10 segment-routing

RP/0/0/CPU0:XR1#sh ip int br
tunnel-te1 192.0.2.21 Up Up default

We can see that the tunnel was signaled successfully, if it wasn't the tunnel wouldn't not become up/up.

RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels 1
Thu May 10 22:34:29.600 UTC

Name: tunnel-te1 Destination: 192.0.2.24 Ifhandle:0x680
Signalled-Name: XR1_t1
Status:
Admin: up Oper: up Path: valid Signalling: connected

path option 5, (Segment-Routing) type explicit SR_TE (Basis for Setup)
Protected-by PO index: none
path option 10, type segment-routing
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Thu May 10 21:31:07 2018 (01:03:23 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: any (default)
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: enabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
History:
Tunnel has been up for: 01:03:22 (since Thu May 10 21:31:08 UTC 2018)
Current LSP:
Uptime: 00:52:10 (since Thu May 10 21:42:20 UTC 2018)
Prior LSP:
ID: 2 Path Option: 10
Removal Trigger: reoptimization completed

Segment-Routing Path Info (OSPF 1 area 0)
Segment0[Node]: 192.0.2.25, Label: 16025
Segment1[Node]: 192.0.2.26, Label: 16026
Segment2[Node]: 192.0.2.22, Label: 16022
Segment3[Node]: 192.0.2.23, Label: 16023
Segment4[Node]: 192.0.2.27, Label: 16027
Segment5[Node]: 192.0.2.28, Label: 16028
Segment6[Node]: 192.0.2.24, Label: 16024
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

The MPLS TE tunnel output shows that SR is being used to build the tunnel, meaning that SR labels will be used and not RSVP-TE which would be labels starting at 24000 and above. The current path being leveraged is option 5, the explicit path, which is defined above.

RP/0/0/CPU0:XR1#sh route 192.0.2.24
Thu May 10 22:35:40.545 UTC

Routing entry for 192.0.2.24/32
Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
Installed May 10 21:31:09.200 for 01:04:31
Routing Descriptor Blocks
192.0.2.24, from 192.0.2.24, via tunnel-te1
Route metric is 4
No advertising protos.

Expanding the route to XR4's loopback, we see that the path now follows the TE1 path and is using a labeled SR path.

RP/0/0/CPU0:XR1#sh cef 192.0.2.24
Thu May 10 22:35:56.954 UTC
192.0.2.24/32, version 46, internal 0x1000001 0x1 (ptr 0xa12b3a74) [1], 0x0 (0xa127f584), 0xa20 (0xa150d320)
Updated May 10 21:31:09.460
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 192.0.2.24/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0f164f0 0xa0f16154]
next hop 192.0.2.24/32
local adjacency
local label 24007 labels imposed {ImplNull}

Looking at the CEF table we can see label 24007 was allocated as adjacency SID since the TE1 tunnel is a new tunnel and therefore a label needs to be allocated.

RP/0/0/CPU0:XR1#sh mpls forwarding labels 24007
Thu May 10 22:50:33.174 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------

24007 Pop 192.0.2.24/32 tt1 192.0.2.24 0

We can prove that by looking at what label 24007 was applied to, in this case it is the TE tunnel.

Once the tunnel is up, re-optimization maybe needed to take the explicit path.

RP/0/0/CPU0:XR1#mpls traffic-eng reoptimize 1

Now that we have a TE tunnel up and running, the routing table shows that traffic towards XR4 will take the TE tunnel. Let's do a trace from XR1 to XR4 and see what happens.

RP/0/0/CPU0:XR1#traceroute 192.0.2.24 source 192.0.2.21 num
Thu May 10 22:36:40.701 UTC

Type escape sequence to abort.
Tracing the route to 192.0.2.24

1 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024 Exp 0] 139 msec 119 msec 109 msec
2 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024 Exp 0] 119 msec 109 msec 149 msec
3 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024 Exp 0] 119 msec 119 msec 119 msec
4 100.64.123.13 [MPLS: Labels 16027/16028/16024 Exp 0] 129 msec 109 msec 119 msec
5 100.64.137.17 [MPLS: Labels 16028/16024 Exp 0] 109 msec 119 msec 119 msec
6 100.64.178.18 [MPLS: Label 16024 Exp 0] 119 msec 129 msec 109 msec
7 100.64.148.14 109 msec * 109 msec

We can see that the TE tunnel is being taken with the 7 SR label stack. This stack is encoded as it hits the ingress PE.

R1#ping 192.0.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/86/90 ms

R1#traceroute 192.0.2.2 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.101.11 19 msec 7 msec 10 msec
2 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024/24004 Exp 0] 131 msec 133 msec 126 msec
3 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024/24004 Exp 0] 143 msec 134 msec 123 msec
4 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024/24004 Exp 0] 143 msec 129 msec 124 msec
5 100.64.123.13 [MPLS: Labels 16027/16028/16024/24004 Exp 0] 140 msec 133 msec 126 msec
6 100.64.137.17 [MPLS: Labels 16028/16024/24004 Exp 0] 141 msec 138 msec 124 msec
7 100.64.178.18 [MPLS: Labels 16024/24004 Exp 0] 135 msec 132 msec 128 msec
8 100.64.148.14 [MPLS: Label 24004 Exp 0] 130 msec 133 msec 127 msec
9 100.64.103.2 133 msec * 136 msec

We see that in the above ping worked, but that doesn't showcase the SR TE output. The traceroute showcases the SR TE stack. The screenshot shows that the entire stack is encoded as traffic enters the SP core.

Thanks for stopping by!

Rob Riker, CCIE #50693