10. segment routing traffic engineering Part2_ SRTE Automatic Traffic Steering using BGP

Preview

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 automated steering

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.

SRTE Automatic Traffic Steering

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.0
RP/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 paths

As 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:1

As 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: yes
RP/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:2

With 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.

segment routing traffic engineering detail concept

Back to: Segment Routing > segment routing traffic engineering

Leave a comment

Your email address will not be published. Required fields are marked *