In the last video, we learned how we can use segment routing traffic engineering Policy to create a traffic engineering path. Then we learned how to manually steer traffic over the traffic engineering path using Binding-SID. In this section we would like to learn how automatoc traffic steering works using BGP.
segment routing traffic engineering part 1
This is the topology that we have used in the last section. If you remember, in xrv1, I created a segment routing traffic engineering path, through xrv2-xrv4-xrv5-xrv6 with Binding-SID 40000. I have also created another policy for the same destination xrv6 in xrv3. Then I enforced the traffic manually from xrv3 to be routed through xrv1 and then Binding-SID 40000, which route the traffic from xrv3 to xrv6 through xrv1-xrv2-xrv4-xrv5-xrv6 instead of the direct path to xrv3-xrv5-xrv6.
However, in this section I want to show how we can steer traffic through the segment routing traffic engineering path automatically using BGP.
Our topology is the same, but this time we have two customers named RAYKA and COMPANY1 who are connected to the PE routers, xrv1 and xrv6. subnets belonging to RAYKA and COMPANY1 are advertised on the network via BGP vpnv4 address-family between xrv1 and xrv6. RAYKA is a GOLD customer which has paid more money and COMPANY1 is SILVER customer which has paid less money.
How does the automatic steering work? There is a simple rule. When the next hop and the color of a route matches, the endpoint and color of a policy, then traffic that matches the route is automatically routed through the active segment routing traffic engineering path associated with that policy.
segment routing traffic engineering policy
To better understand, in xrv1, I have created two policies. First, GOLD policy with endpoint 6.6.6.6 and color 10 (GOLD), whose active traffic engineering path is through xrv1-xrv2-xrv4-xrv5-xrv6. The second policy is SILVER with endpoint 6.6.6.6 and color 20 (SILVE), whose active traffic engineering path is through xrv1-xrv3-xrv5-xrv6.
RP/0/RP0/CPU0:xrv1#show runn segment-routing
Sat Jul 10 20:31:57.246 UTC
segment-routing
traffic-eng
segment-list xrv3-xrv5-xrv6
index 10 mpls label 16003
index 20 mpls label 16005
index 30 mpls label 16006
!
segment-list xrv2-xrv4-xrv5-xrv6
index 10 mpls label 16004
index 20 mpls label 16005
index 30 mpls label 16006
!
policy PE2_GOLD
binding-sid mpls 40000
color 10 end-point ipv4 6.6.6.6
candidate-paths
preference 80
dynamic
metric
type igp
!
!
!
preference 100
explicit segment-list xrv2-xrv4-xrv5-xrv6
!
!
!
!
policy PE2_SILVER
color 20 end-point ipv4 6.6.6.6
candidate-paths
preference 80
dynamic
metric
type igp
!
!
!
preference 100
explicit segment-list xrv3-xrv5-xrv6
!
!
!
!
!
! mark customer routes with their respective SLA
It is normal that when we advertise customers route in the network, we assign a tag to their routes equivalent to their services. So in xrv6, I add color 10 to RAYKA subnets and color 20 to COMPANY1 subnets with extended community when advertising through BGP.
RP/0/RP0/CPU0:xrv6#show running-config extcommunity-set opaque GOLD
Sat Jul 10 20:33:57.510 UTC
extcommunity-set opaque GOLD
10
end-set
!
RP/0/RP0/CPU0:xrv6#show running-config extcommunity-set opaque SILVER
Sat Jul 10 20:34:04.380 UTC
extcommunity-set opaque SILVER
20
end-set
!
RP/0/RP0/CPU0:xrv6#show runn route-policy vpnv4
Sat Jul 10 20:34:15.273 UTC
route-policy vpnv4
if destination in (192.168.2.0/24) then
set extcommunity color GOLD
elseif destination in (192.168.3.0/24) then
set extcommunity color SILVER
else
pass
endif
end-policy
!
RP/0/RP0/CPU0:xrv6#show runn router bgp
Sat Jul 10 20:34:27.204 UTC
router bgp 1
bgp router-id 6.6.6.6
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor 1.1.1.1
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
route-policy vpnv4 out
!
!
vrf RAYKA
rd 1:1
address-family ipv4 unicast
redistribute connected
!
!
vrf COMPANY1
rd 1:2
address-family ipv4 unicast
redistribute connected
!
!
!When xrv1 receives the routes, the next hop of the routes are 6.6.6.6 and the color of the routes are 10 or 20 according to the customer. It means that the routes will be matched with one of these two policies so traffics matching these routes will be automatically steered through segment routing traffic engineering path, active in the policies.
So we can expect that traffic from xrv1 and belonging to RAYKA customer will be steered automatically through xrv2-xrv4-xrv5-xrv6 and traffic belonging to COMPANY1 customer will be steered automatically through xrv3-xrv5-xrv6.
review segment routing traffic engineering automatic steering configuration
Now I would like to review the entire configuration first and then monitor the engineering path of the segment routing.
my configuration is classified in 5 Steps. In the first step, ISIS and segment routing are activated in all routers. The configuration of xrv1 is displayed here. As you can see, ISIS is activated in all interfaces. The segment routing is activated with the command “segment-routing mpls”. The prefix-SID of Loopback0 of all routers is configured from 16001 to 1606.
RP/0/RP0/CPU0:xrv1#show runn router isis
Sat Jul 10 20:36:21.131 UTC
router isis LAB
is-type level-2-only
net 49.0000.0000.0001.00
distribute link-state
address-family ipv4 unicast
metric-style wide
segment-routing mpls
!
interface Loopback0
address-family ipv4 unicast
prefix-sid absolute 16001
!
!
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
metric 15
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4 unicast
!
!
!In Step 2, vrf of RAYKA and COMPANY1 are created in PE routers, xrv1 and xrv6. import RT/export RT of RAYKA vrf is assigned to 1:1 and import RT/export RT of COMPANY1 vrf is assigned to 1:2. Interface loopback 1 is assigned to vrf RAYKA and loopback 2 is assigned to vrf COMPANY1 .
RP/0/RP0/CPU0:xrv1#show runn vrf
Sat Jul 10 20:37:05.150 UTC
vrf RAYKA
address-family ipv4 unicast
import route-target
1:1
!
export route-target
1:1
!
!
!
vrf COMPANY1
address-family ipv4 unicast
import route-target
1:2
!
export route-target
1:2
!
!
!
RP/0/RP0/CPU0:xrv1#show runn interface loopback 1
Sat Jul 10 20:37:39.528 UTC
interface Loopback1
vrf RAYKA
ipv4 address 192.168.1.1 255.255.255.0
!
RP/0/RP0/CPU0:xrv1#show runn interface loopback 2
Sat Jul 10 20:37:43.142 UTC
interface Loopback2
vrf COMPANY1
ipv4 address 192.168.1.1 255.255.255.0RP/0/RP0/CPU0:xrv6#show runn vrf
Sat Jul 10 20:38:36.607 UTC
vrf RAYKA
address-family ipv4 unicast
import route-target
1:1
!
export route-target
1:1
!
!
!
vrf COMPANY1
address-family ipv4 unicast
import route-target
1:2
!
export route-target
1:2
!
!
!
RP/0/RP0/CPU0:xrv6# show runn interface loopback 1
Sat Jul 10 20:38:42.295 UTC
interface Loopback1
vrf RAYKA
ipv4 address 192.168.2.1 255.255.255.0
!
RP/0/RP0/CPU0:xrv6# show runn interface loopback 2
Sat Jul 10 20:38:44.707 UTC
interface Loopback2
vrf COMPANY1
ipv4 address 192.168.3.1 255.255.255.0
!In Step 3, BGP between xrv1 and xrv6 with address-family VPNV4 is configured. IP address of loopback interfaces belonging to customer VRFs are redistributed into BGP and advertised through VPNV4 address-family between xrv1 and xrv6.
RP/0/RP0/CPU0:xrv1#show runn router bgp
Sat Jul 10 20:40:16.008 UTC
router bgp 1
bgp router-id 1.1.1.1
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor 6.6.6.6
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
!
vrf RAYKA
rd 1:1
address-family ipv4 unicast
redistribute connected
!
!
vrf COMPANY1
rd 1:2
address-family ipv4 unicast
redistribute connected
!
!
!In step 3, routes received from customers in xrv6 are marked with their respective SLA service. Routes from RAYKA customers are colored with number 10 as GOLD service and routes from COMPANY1 customers are colored with number 20 as SILVER service. Then these colors are advertised with their routes through BGP. These routes are received in router xrv1 with the next-hop address 6.6.6.6 and with color 10 or 20.
RP/0/RP0/CPU0:xrv6#show running-config extcommunity-set opaque GOLD
Sat Jul 10 20:33:57.510 UTC
extcommunity-set opaque GOLD
10
end-set
!
RP/0/RP0/CPU0:xrv6#show running-config extcommunity-set opaque SILVER
Sat Jul 10 20:34:04.380 UTC
extcommunity-set opaque SILVER
20
end-set
!
RP/0/RP0/CPU0:xrv6#show runn route-policy vpnv4
Sat Jul 10 20:34:15.273 UTC
route-policy vpnv4
if destination in (192.168.2.0/24) then
set extcommunity color GOLD
elseif destination in (192.168.3.0/24) then
set extcommunity color SILVER
else
pass
endif
end-policy
!
RP/0/RP0/CPU0:xrv6#show runn router bgp
Sat Jul 10 20:34:27.204 UTC
router bgp 1
bgp router-id 6.6.6.6
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor 1.1.1.1
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
route-policy vpnv4 out
!
!
vrf RAYKA
rd 1:1
address-family ipv4 unicast
redistribute connected
!
!
vrf COMPANY1
rd 1:2
address-family ipv4 unicast
redistribute connected
!
!
!In router xrv1, we write two segment routing traffic engineering policies, one for endpoint 6.6.6.6 and color 10 named GOLD and the other with endpoint 6.6.6.6 and color 20. Named SILVER.
RP/0/RP0/CPU0:xrv1#show runn segment-routing
Sat Jul 10 20:42:20.464 UTC
segment-routing
traffic-eng
segment-list xrv3-xrv5-xrv6
index 10 mpls label 16003
index 20 mpls label 16005
index 30 mpls label 16006
!
segment-list xrv2-xrv4-xrv5-xrv6
index 10 mpls label 16004
index 20 mpls label 16005
index 30 mpls label 16006
!
policy PE2_GOLD
binding-sid mpls 40000
color 10 end-point ipv4 6.6.6.6
candidate-paths
preference 80
dynamic
metric
type igp
!
!
!
preference 100
explicit segment-list xrv2-xrv4-xrv5-xrv6
!
!
!
!
policy PE2_SILVER
color 20 end-point ipv4 6.6.6.6
candidate-paths
preference 80
dynamic
metric
type igp
!
!
!
preference 100
explicit segment-list xrv3-xrv5-xrv6
!
!
!
!
!
! The preferred path of GOLD policy is through xrv2-xrv4-xrv5-xrv6 and the preferred path of SILVER policy is through xrv3-xrv5-xrv6.
Since these policies are matched with incoming routes, so the traffic matching the routes will be automatically steered through traffic engineering path configured inside the policy.
monitoring automatic steering
Let’s check the routes that are advertised through BGP.
RP/0/RP0/CPU0:xrv1#show bgp vpnv4 unicast
Sat Jul 10 20:43:13.978 UTC
BGP router identifier 1.1.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 55
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf RAYKA)
*> 192.168.1.0/24 0.0.0.0 0 32768 ?
*>i192.168.2.0/24 6.6.6.6 C:10 0 100 0 ?
Route Distinguisher: 1:2 (default for vrf COMPANY1)
*> 192.168.1.0/24 0.0.0.0 0 32768 ?
*>i192.168.3.0/24 6.6.6.6 C:20 0 100 0 ?
Processed 4 prefixes, 4 pathsAs you can see, the routes are learned with their respective color. 192.168.2.0/24 for the company RAYKA is learned with the color 10 and 192.168.3.0/24 for the company 1 with the color 20.
With the command “show bgp vpnv4 unicast vrf RAYKA 192.168.2.0/24” you can see the details of received route, including the color and if it matched with a traffic engineering policy.
RP/0/RP0/CPU0:xrv1# show bgp vpnv4 unicast vrf RAYKA 192.168.2.0/24
Sat Jul 10 20:44:09.641 UTC
BGP routing table entry for 192.168.2.0/24, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 53 53
Last Modified: Jul 9 10:12:42.048 for 1d10h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
6.6.6.6 C:10 (bsid:40000) (metric 40) from 6.6.6.6 (6.6.6.6)
Received Label 24005
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 53
Extended community: Color:10 RT:1:1
SR policy color 10, up, not-registered, bsid 40000
Source AFI: VPNv4 Unicast, Source VRF: RAYKA, Source Route Distinguisher: 1:1As you can see, route 192.168.2.0/24 is matched against GOLD policy with binding-SID 40000 which is configured manually. but the route 192.168.3.0/24 is matched with the SILVER policy with dynamic binding-SID. You can check the dynamic binding-SID with the command “show segment-routing traffic-eng policy” and with the command “show bgp vpnv4 unicast vrf RAYKA 192.168.3.0/24” check whether this route is bound to the dynamic binding-SID.
RP/0/RP0/CPU0:xrv1#show segment-routing traffic-eng policy
Sat Jul 10 20:45:18.194 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 6.6.6.6
Name: srte_c_10_ep_6.6.6.6
Status:
Admin: up Operational: up for 3d23h (since Jul 6 20:55:21.443)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: PE2_GOLD
Requested BSID: 40000
Explicit: segment-list xrv2-xrv4-xrv5-xrv6 (valid)
Weight: 1, Metric Type: TE
16004 [Prefix-SID, 4.4.4.4]
16005
16006
Preference: 80 (configuration)
Name: PE2_GOLD
Requested BSID: 40000
Dynamic (invalid)
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 40000
Forward Class: Not Configured
Steering BGP disabled: no
IPv6 caps enable: yes
Color: 20, End-point: 6.6.6.6
Name: srte_c_20_ep_6.6.6.6
Status:
Admin: up Operational: up for 2d05h (since Jul 8 15:16:29.949)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: PE2_SILVER
Requested BSID: dynamic
Explicit: segment-list xrv3-xrv5-xrv6 (valid)
Weight: 1, Metric Type: TE
16003 [Prefix-SID, 3.3.3.3]
16005
16006
Preference: 80 (configuration)
Name: PE2_SILVER
Requested BSID: dynamic
Dynamic (invalid)
Last error: No path found
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 24009
Forward Class: Not Configured
Steering BGP disabled: no
IPv6 caps enable: yesRP/0/RP0/CPU0:xrv1#show bgp vpnv4 unicast vrf COMPANY1 192.168.3.0/24
Sat Jul 10 20:46:26.876 UTC
BGP routing table entry for 192.168.3.0/24, Route Distinguisher: 1:2
Versions:
Process bRIB/RIB SendTblVer
Speaker 55 55
Last Modified: Jul 9 10:15:05.048 for 1d10h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
6.6.6.6 C:20 (bsid:24009) (metric 40) from 6.6.6.6 (6.6.6.6)
Received Label 24004
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 55
Extended community: Color:20 RT:1:2
SR policy color 20, up, not-registered, bsid 24009
Source AFI: VPNv4 Unicast, Source VRF: COMPANY1, Source Route Distinguisher: 1:2With traceroute we can also ensure that the traffic in connection with RAYKA and COMPANY 1 are routed via their respective traffic engineering path.
RP/0/RP0/CPU0:xrv1#traceroute vrf RAYKA 192.168.2.1
Sat Jul 10 20:47:55.384 UTC
Type escape sequence to abort.
Tracing the route to 192.168.2.1
1 10.1.2.2 [MPLS: Labels 16004/16005/16006/24005 Exp 0] 54 msec 35 msec 42 msec
2 10.2.4.4 [MPLS: Labels 16005/16006/24005 Exp 0] 39 msec 38 msec 40 msec
3 10.4.5.5 [MPLS: Labels 16006/24005 Exp 0] 26 msec 43 msec 40 msec
4 10.5.6.6 50 msec * 47 msec RP/0/RP0/CPU0:xrv1#traceroute vrf COMPANY1 192.168.3.1
Sat Jul 10 20:49:07.022 UTC
Type escape sequence to abort.
Tracing the route to 192.168.3.1
1 10.1.3.3 [MPLS: Labels 16005/16006/24004 Exp 0] 31 msec 35 msec 35 msec
2 10.3.5.5 [MPLS: Labels 16006/24004 Exp 0] 31 msec 27 msec 23 msec
3 10.5.6.6 52 msec * 47 msec So the traffic are routed through their respective path configured in traffic engineering policy.