SRTE configuration

Below a list of the necessary elements to know when forging an SR policy.

Basic segment routing policy configuration

The configured services rely on a SR configuration with the IS-IS protocol. The rt1 device will be configured to steer 10.200.0.0/24 traffic to the rt4 device. The configuration example is given in SRTE setup example. The below figure can help:

../../../../_images/srte_basic1.svg

Basic topology example to illustrate segment routing policies configuration.

Color configuration

As explained in the SRTE overview chapter, coloring is necessary to steer traffic in a SR network. The color is an arbitrary value associated with a routing entry. Color can be set by route-maps. The incoming BGP routes can be locally colored.

rt1

rt1 running config# vrf main
rt1 running vrf main# routing bgp
rt1 running bgp#! as 65500
rt1 running bgp# router-id 1.1.1.1
rt1 running bgp# network-import-check false
rt1 running bgp# address-family ipv4-unicast network 10.100.0.0/24
rt1 running network 10.100.0.0/24# / vrf main routing bgp neighbor 4.4.4.4 remote-as 65500
rt1 running bgp# neighbor 4.4.4.4 update-source loop1
rt1 running bgp# neighbor 4.4.4.4 address-family ipv4-unicast route-map in route-map-name rmap
rt1 running bgp#! / routing route-map rmap
rt1 running route-map rmap#! seq 10 policy permit
rt1 running route-map rmap# seq 10 set sr-te color 5
rt1 running route-map rmap#

rt4

rt4 running config# vrf main
rt4 running vrf main# routing bgp
rt4 running bgp#! as 65500
rt4 running bgp# router-id 4.4.4.4
rt4 running bgp# network-import-check false
rt4 running bgp# address-family ipv4-unicast network 10.200.0.0/24
rt4 running network 10.100.0.0/24# / vrf main routing bgp neighbor 1.1.1.1 remote-as 65500
rt4 running bgp# neighbor 1.1.1.1 update-source loop1
rt4 running bgp#

rt1

rt1# show bgp ipv4
BGP table version is 2, local router ID is 1.1.1.1, vrf id 0
Default local pref 100, local AS 65500
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.100.0.0/24    0.0.0.0                  0         32768 i
*>i10.200.0.0/24    4.4.4.4                  0    100      0 i

Displayed  2 routes and 2 total paths

The above configuration colors the BGP route to the 10.200.0.024 traffic. The incoming traffic entering the SR network and going to the 10.200.0.024 network will have the same characteristics.

Without the SR policy, the LSP path to the 10.200.0.024 network reuses the SID returned by the SR network.

rt1

rt1# show ipv4-routes
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

C>* 1.1.1.1/32 is directly connected, loop1, 11:55:17
[..]
I>* 3.3.3.3/32 [115/30] via 10.125.0.2, eth3, label 1033, weight 1, 00:01:59
I>* 4.4.4.4/32 [115/40] via 10.125.0.2, eth3, label 1044, weight 1, 11:54:32
B>  10.200.0.0/24 [200/0] via 4.4.4.4 (recursive), weight 1, 11:35:18
  *                         via 10.125.0.2, eth3, label 1044, weight 1, 11:35:18

The below dump indicates that only the 32001 adjacency label reuses the eth2 interface directly connected to the rt3 device.

rt1

rt1# show mpls table
 Inbound Label  Type        Nexthop     Outbound Label
 -------------------------------------------------------
 1011           SR (IS-IS)  lo          -
 1022           SR (IS-IS)  10.125.0.2  1022
 1033           SR (IS-IS)  10.125.0.2  1033
 1044           SR (IS-IS)  10.125.0.2  1044
 32000          SR (IS-IS)  10.125.0.2  implicit-null
 32001          SR (IS-IS)  10.130.0.3  implicit-null

Candidate Path configuration

The below configuration illustrates an SR policy used to steer traffic going to the 4.4.4.4 endpoint, and with a color set to 5. The SR policy must have one or more candidate paths returning a segment list, ordered by preference number. The active candidate paths with the highest preference number is chosen by the SR policy to use the returned segment list.

A candidate path can be either explicit or dynamic.

Explicit segment List configuration using SID labels

On the former case, a segment-list needs to be configured:

rt1

rt1 running vrf main# routing segment-routing enabled true
rt1 running vrf main# routing segment-routing traffic-engineering
rt1 running traffic-engineering# policy color 5 endpoint 4.4.4.4
rt1 running policy color 5 endpoint 4.4.4.4# name 10_200_to_node4
rt1 running policy color 5 endpoint 4.4.4.4# candidate-path 10 type explicit name force_lsp segment-list igp_lsp
rt1 running policy color 5 endpoint 4.4.4.4#! ..
rt1 running traffic-engineering#! segment-list igp_lsp
rt1 running segment-list igp_lsp# segment 10 sid-label 1033
rt1 running segment-list igp_lsp# segment 20 sid-label 1044
rt1 running segment-list igp_lsp#

A segment list is a list of segments indexed by a number. The prioritized segment is that with the lowest index. In MPLS, the top segment stands for the first MPLS label that is used when entering a SR network. That label must be available in the SIDs offered by the SR network. If not, the candidate path associated with the segment list will not be valid, and the SR policy will be Inactive.

rt1

rt1> show segment-routing te-policies
 Endpoint  Color  Name                 BSID  Status
 ----------------------------------------------------
 4.4.4.4   5      10_200_to_node4      -     Active

The above SR policy is active because the 1033 label is available in the MPLS table, as indicated by the below output:

rt1

rt1> show mpls table
 Inbound Label  Type        Nexthop     Outbound Label
 -------------------------------------------------------
 1011           SR (IS-IS)  lo          -
 1022           SR (IS-IS)  10.125.0.2  1022
 1033           SR (IS-IS)  10.125.0.2  1033
 1044           SR (IS-IS)  10.125.0.2  1044
 32000          SR (IS-IS)  10.125.0.2  implicit-null
 32001          SR (IS-IS)  10.130.0.3  implicit-null

Once the SR policy is active, the routing entries with the next-hop set to the 4.4.4.4 address, and with the color set to 5 are modified. The segment list becomes the <1033, 1044> sid list.

rt1

rt1> show segment-routing te-policies installed
 Endpoint  Color  Name                 Status  Local Label  Segment List
 4.4.4.4   5     to_10_200_to_node4    Active  None         1033/1044

The colored BGP route will benefit from this SID list and the label stack will reflect the new segment list.

rt1

rt1# show ipv4-routes
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

C>* 1.1.1.1/32 is directly connected, loop1, 11:55:17
[..]
I>* 4.4.4.4/32 [115/40] via 10.125.0.2, eth3, label 1044, weight 1, 11:54:32
B>  10.200.0.0/24 [200/0] via 4.4.4.4 (recursive), weight 1, 11:35:18
  *                         via 10.125.0.2, eth3, label 1033/1044, weight 1, 00:00:05

Note

The labels used on the above example do not use the eth2 interface, as the 1033 label is reachable via IS-IS through the eth3 interface.

When the explicit segment list is expressed with MPLS labels, the segment list is hardset and never changes.

Explicit Segment List configuration using adjacency IP addresses

There are other ways to express segment lists in the configuration, which consists of naming the IPv4 and the IPv6 adjacencies of the SR network.

See also

  • Segment types definitions: see RFC 9256, section 4.

The below configuration illustrates a segment-list based on NAI IPv4 adjacencies. NAI stands for node or adjacency identifier.

The segment list expressed with IP addresses need to get information on which label to use to reach a given IP adjacency. This information is known by the IGP routing protocol: IS-IS has a TE database that collects various information about nodes, and links. The edge information correlates SR information with IP information, and is used by SR-TE to resolve the NAI segments.

To enable the TE information on the IS-IS instances of the SR devices, perform the following configuration:

rt1

rt1 running vrf main# routing
rt1 running routing# interface eth2
rt1 running interface eth2# isis area-tag 1
rt1 running interface eth2#! isis ipv4-routing true
rt1 running interface eth2# isis ipv6-routing true
rt1 running interface eth2# isis network-point-to-point true
rt1 running interface eth2# traffic-engineering
rt1 running traffic-enginerring# .. ..
rt1 running routing# interface eth3
rt1 running interface eth3# isis area-tag 1
rt1 running interface eth3#! isis ipv4-routing true
rt1 running interface eth3# isis ipv6-routing true
rt1 running interface eth3# isis network-point-to-point true
rt1 running interface eth3# traffic-engineering
rt1 running traffic-engineering# .. ..
rt1 running routing# isis instance 1
rt1 running instance 1# traffic-engineering ipv4-router-address 1.1.1.1
rt1 running instance 1# traffic-engineering ipv6-router-address 1:1::1:1

rt2

rt2 running vrf main# routing
rt2 running routing# interface eth1
rt2 running interface eth1# isis area-tag 1
rt2 running interface eth1#! isis ipv4-routing true
rt2 running interface eth1# isis ipv6-routing true
rt2 running interface eth1# isis network-point-to-point true
rt2 running interface eth1# traffic-engineering
rt2 running traffic-engineering# .. ..
rt2 running routing# interface eth2
rt2 running interface eth2# isis area-tag 1
rt2 running interface eth2#! isis ipv4-routing true
rt2 running interface eth2# isis ipv6-routing true
rt2 running interface eth2# isis network-point-to-point true
rt2 running interface eth2# traffic-engineering
rt2 running traffic-engineering# .. ..
rt2 running routing# isis instance 1
rt2 running instance 1# traffic-engineering ipv4-router-address 2.2.2.2
rt2 running instance 1# traffic-engineering ipv6-router-address 2:2::2:2

rt3

rt3 running vrf main# routing
rt3 running routing# interface eth1
rt3 running interface eth1# isis area-tag 1
rt3 running interface eth1#! isis ipv4-routing true
rt3 running interface eth1# isis ipv6-routing true
rt3 running interface eth1# isis network-point-to-point true
rt3 running interface eth1# traffic-engineering
rt3 running traffic-engineering# .. ..
rt3 running routing# interface eth2
rt3 running interface eth2# isis area-tag 1
rt3 running interface eth2#! isis ipv4-routing true
rt3 running interface eth2# isis ipv6-routing true
rt3 running interface eth2# isis network-point-to-point true
rt3 running interface eth2# traffic-engineering
rt3 running traffic-engineering# .. ..
rt3 running routing# interface eth3
rt3 running interface eth3# isis area-tag 1
rt3 running interface eth3#! isis ipv4-routing true
rt3 running interface eth3# isis ipv6-routing true
rt3 running interface eth3# isis network-point-to-point true
rt3 running interface eth3# traffic-engineering
rt3 running traffic-engineering# .. ..
rt3 running routing# isis instance 1
rt3 running instance 1# traffic-engineering ipv4-router-address 3.3.3.3
rt3 running instance 1# traffic-engineering ipv6-router-address 3:3::3:3
rt3 running instance 1#

rt4

rt4 running vrf main# routing
rt4 running routing# interface eth1
rt4 running interface eth1# isis area-tag 1
rt4 running interface eth1#! isis ipv4-routing true
rt4 running interface eth1# isis ipv6-routing true
rt4 running interface eth1# isis network-point-to-point true
rt4 running interface eth1# traffic-engineering
rt4 running traffic-engineering# .. ..
rt4 running routing# interface eth2
rt4 running interface eth2# isis area-tag 1
rt4 running interface eth2#! isis ipv4-routing true
rt4 running interface eth2# isis ipv6-routing true
rt4 running interface eth2# isis network-point-to-point true
rt4 running interface eth2# traffic-engineering
rt4 running traffic-engineering# .. ..
rt4 running routing# isis instance 1
rt4 running instance 1# traffic-engineering ipv4-router-address 4.4.4.4
rt4 running instance 1# traffic-engineering ipv6-router-address 4:4::4:4
rt4 running instance 1#

The following command dumps the edge information from the TE database. As it can be seen, the relationship between SR information and adjacency IP addresses is expressed:

rt1

rt1# show isis segment-routing te-database detail
Area 1:
[..]
  Edge (176095235): 10.127.0.3  Adv. Vertex: 0007.e901.3333     Metric: 10      Status: Sync
    Origin: ISIS_L1
    Local IPv4 address: 10.127.0.3
    Remote IPv4 address: 10.127.0.4
    Maximum Bandwidth: 1.76258e+08 (Bytes/s)
    Maximum Reservable Bandwidth: 1.76258e+08 (Bytes/s)
    Unreserved Bandwidth per Class Type
        [0]: 1.76258e+08 (Bytes/sec)    [1]: 1.76258e+08 (Bytes/s)
        [2]: 1.76258e+08 (Bytes/sec)    [3]: 1.76258e+08 (Bytes/s)
        [4]: 1.76258e+08 (Bytes/sec)    [5]: 1.76258e+08 (Bytes/s)
        [6]: 1.76258e+08 (Bytes/sec)    [7]: 1.76258e+08 (Bytes/s)
    IPv4 Adjacency-SID: 33002   Flags: 0x30     Weight: 0x0

  Edge (176291841): 10.130.0.1  Adv. Vertex: 0007.e901.1111     Metric: 25      Status: Sync
    Origin: ISIS_L1
    Local IPv4 address: 10.130.0.1
    Remote IPv4 address: 10.130.0.3
    Maximum Bandwidth: 1.76258e+08 (Bytes/s)
    Maximum Reservable Bandwidth: 1.76258e+08 (Bytes/s)
    Unreserved Bandwidth per Class Type
        [0]: 1.76258e+08 (Bytes/sec)    [1]: 1.76258e+08 (Bytes/s)
        [2]: 1.76258e+08 (Bytes/sec)    [3]: 1.76258e+08 (Bytes/s)
        [4]: 1.76258e+08 (Bytes/sec)    [5]: 1.76258e+08 (Bytes/s)
        [6]: 1.76258e+08 (Bytes/sec)    [7]: 1.76258e+08 (Bytes/s)
    IPv4 Adjacency-SID: 32000   Flags: 0x30     Weight: 0x0
 [..]

The below configuration illustrates how the NAI segment list configuration is used. The traffic heading to the 4.4.4.4 IP address and which is colored is steered by using the adjacency label on the 10.130.0.0/24 network, then on the 10.127.0.0/24 network.

rt1

rt1 running vrf main# routing segment-routing enabled true
rt1 running vrf main# routing segment-routing traffic-engineering
rt1 running traffic-engineering# mpls-te-database import isis
rt1 running traffic-engineering# mpls-te-database enabled true
rt1 running traffic-engineering# policy color 5 endpoint 4.4.4.4
rt1 running policy color 5 endpoint 4.4.4.4# name 10_200_to_node4
rt1 running policy color 5 endpoint 4.4.4.4# candidate-path 20 type explicit name force_lsp_2 segment-list igp_lsp_2
rt1 running policy color 5 endpoint 4.4.4.4#! ..
rt1 running traffic-engineering#! segment-list igp_lsp_2
rt1 running segment-list igp_lsp_2# segment 10 nai adjacency source 10.130.0.1
rt1 running segment-list igp_lsp_2# segment 10 nai adjacency destination 10.130.0.3
rt1 running segment-list igp_lsp_2# segment 20 nai adjacency source 10.127.0.3
rt1 running segment-list igp_lsp_2# segment 20 nai adjacency destination 10.127.0.4
rt1 running segment-list igp_lsp_2#

The SR policy is updated and a new SID list is obtained:

rt1

rt1> show segment-routing te-policies detail
Endpoint: 4.4.4.4  Color: 5  Name: 10_200_to_node4  BSID: -  Status: Active
* Preference: 20  Name: force_lsp_2  Type: explicit  Segment-List: igp_lsp_2  Protocol-Origin: Unknown
    SID-list: 32000 33002

When the NAI type is used in segment list, then the MPLS values translated may vary over the time, since the TE information shared is periodically updated. Then, if there is a change in the SR network due to failover, the segment list is updated, and the changes are propagated to the SR policy.

Note

The segment list can be defined by a set of different segment types. For instance the first entry can be an MPLS label, while the second will be expressed by an IP adjacency.

Candidate paths using Flex-Algorithm

The below SR-TE configuration sets an IS-IS instance with the area-tag number 1 annd with the Flex Algorithm configured with the identifier number 129:

rt1

rt1 running config# routing traffic-engineering affinity-map red bit-position 1
rt1 running config# routing traffic-engineering affinity-map green bit-position 0
rt1 running config# vrf main routing interface eth2
rt1 running interface eth2# traffic-engineering affinity-map green
rt1 running interface eth2# isis network-point-to-point true
rt1 running interface eth2# .. eth3
rt1 running interface eth3# traffic-engineering affinity-map red
rt1 running interface eth3# isis network-point-to-point true
rt1 running interface eth3# .. isis instance 1
rt1 running instance 1# traffic-engineering ipv4-router-address 1.1.1.1
rt1 running instance 1# flex-algorithm 129
rt1 running flex-algorithm 129#
rt1 running flex-algorithm 129# dataplane sr-mpls
rt1 running flex-algorithm 129# priority 150
rt1 running flex-algorithm 129# definition advertise true
rt1 running flex-algorithm 129# definition affinity exclude-any red
rt1 running flex-algorithm 129# definition affinity include-any green
rt1 running flex-algorithm 129# segment-routing prefix-sid-map 1.1.1.1/32 sid-value 110
rt1 running flex-algorithm 129# segment-routing prefix-sid-map 1.1.1.1/32 last-hop-behavior no-php

rt2

rt2 running config# routing traffic-engineering affinity-map red bit-position 1
rt2 running config# routing traffic-engineering affinity-map green bit-position 0
rt2 running config# vrf main routing interface eth1
rt2 running interface eth1# traffic-engineering affinity-map red
rt2 running interface eth1# isis network-point-to-point true
rt2 running interface eth1# .. eth2
rt2 running interface eth2# traffic-engineering affinity-map green
rt2 running interface eth2# isis network-point-to-point true
rt2 running interface eth2# .. isis instance 1
rt2 running instance 1# traffic-engineering ipv4-router-address 2.2.2.2
rt2 running instance 1# flex-algorithm 129
rt2 running flex-algorithm 129# dataplane sr-mpls
rt2 running flex-algorithm 129# segment-routing prefix-sid-map 2.2.2.2/32 sid-value 220
rt2 running flex-algorithm 129# segment-routing prefix-sid-map 2.2.2.2/32 last-hop-behavior no-php

rt3

rt3 running config# routing traffic-engineering affinity-map red bit-position 1
rt3 running config# routing traffic-engineering affinity-map green bit-position 0
rt3 running config# vrf main routing interface eth1
rt3 running interface eth1# traffic-engineering affinity-map green
rt3 running interface eth1# isis network-point-to-point true
rt3 running interface eth1# .. eth2
rt3 running interface eth2# traffic-engineering affinity-map green
rt3 running interface eth2# isis network-point-to-point true
rt3 running interface eth2# .. eth3
rt3 running interface eth3# traffic-engineering affinity-map green
rt3 running interface eth3# isis network-point-to-point true
rt3 running interface eth3# .. isis instance 1
rt3 running instance 1# traffic-engineering ipv4-router-address 3.3.3.3
rt3 running instance 1# flex-algorithm 129
rt3 running flex-algorithm 129# dataplane sr-mpls
rt3 running flex-algorithm 129# segment-routing prefix-sid-map 3.3.3.3/32 sid-value 330
rt3 running flex-algorithm 129# segment-routing prefix-sid-map 3.3.3.3/32 last-hop-behavior no-php

rt4

rt4 running config# routing traffic-engineering affinity-map red bit-position 1
rt4 running config# routing traffic-engineering affinity-map green bit-position 0
rt4 running config# vrf main routing interface eth2
rt4 running interface eth2# traffic-engineering affinity-map green
rt4 running interface eth2# isis network-point-to-point true
rt4 running interface eth2# .. isis instance 1
rt4 running instance 1# traffic-engineering ipv4-router-address 4.4.4.4
rt4 running instance 1# flex-algorithm 129
rt4 running flex-algorithm 129# dataplane sr-mpls
rt4 running flex-algorithm 129# segment-routing prefix-sid-map 4.4.4.4/32 sid-value 330
rt4 running flex-algorithm 129# segment-routing prefix-sid-map 4.4.4.4/32 last-hop-behavior no-php

See also

The following configuration creates an SR policy that follows the routing updates given by the Flexible Algorithm configured by IS-IS.

rt1

rt1 running vrf main# routing segment-routing enabled true
rt1 running vrf main# routing segment-routing traffic-engineering
rt1 running traffic-engineering# flex-algorithm import isis instance 1
rt1 running traffic-engineering# policy color 5 endpoint 4.4.4.4
rt1 running policy color 5 endpoint 4.4.4.4# name 10_200_to_node4
rt1 running policy color 5 endpoint 4.4.4.4# candidate-path 30 name force_lsp_3 type flex-algorithm algorithm 129
rt1 running policy color 5 endpoint 4.4.4.4#

The routing updates related to the 4.4.4.4 endpoint are propagated to the SR policy. The colored routes using the 4.4.4.4 nexthop as endpoint will use the provided segment-list.

rt1

rt1> show segment-routing te-policies detail
Endpoint: 1.1.1.1  Color: 1  Name:   BSID: 501  Status: Active
  * Preference: 30  Name: flex_algo  Type: flex-algo  Segment-List: flex_algo-fa-p10  Protocol-Origin: Local
      SID-list: 1440

rt1

rt1> show ipv4-routes protocol bgp
north-vm> show ipv-routes protocol bgp
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

B>  10.200.0.0/24 [200/0] via 4.4.4.4 (recursive), weight 1, 00:28:45
  *                         via 10.130.0.3, eth2, label 1440, weight 1, 00:28:45

Flex-Algorithm candidate paths follow the segment list definition given by the IS-IS Flex-Algorithm definition. If there is a change in the SR network due to failover, then the Flex-Algorithm is informed, and propagates this change to the SR policy. For instance, when there is a failover on a link, a backup path may be put in place to repair the broken link, or the broken adjacency node.

BSID configuration

BSID stands for the SID value that uniquely identifies an SR policy. For SR MPLS dataplanes, this value is an MPLS label. The BSID is used to perform switching operations on the local device, instead of doing routing operations: the incoming traffic having that MPLS value will be steered by the corresponding SR policy, and the BSID will be popped and replaced by the segment-list of the active candidate-path.

It is recommended to configure the BSID for each SR policy, like shown below:

rt1

rt1 running vrf main# routing segment-routing enabled true
rt1 running vrf main# routing segment-routing traffic-engineering
rt1 running traffic-engineering# policy color 5 endpoint 4.4.4.4
rt1 running policy color 5 endpoint 4.4.4.4# binding-sid 600
rt1 running policy color 5 endpoint 4.4.4.4#

BSID helps for scaling, as it is used to extend the MPLS networks to upstream devices. The below figure shows an upstream router that want to stick its traffic to a given SR policy:

../../../../_images/srte_basic_upstream_router.svg

Usage of traffic engineering in segment routing with an MPLS based upstream device

After having configured the return route, and having configured the BSID on the upstream router, if the SR policy has an active candidate path, then an MPLS entry will be added, and will switch the incoming traffic with the segment-list of the SR policy.

rt1

rt1 running vrf main# interface physical eth1
rt1 running interface eth1# port pci-b0s4
rt1 running interface eth1# ipv4-address 10.100.0.1/24
rt1 running interface eth1# .. ..
rt1 running vrf main# routing static ipv4-route 10.101.0.0/24 next-hop 10.100.0.20 label 3
rt1 running vrf main#

upstream_router

upstream_router running vrf main# interface physical eth1
upstream_router running interface eth1# port pci-b0s5
upstream_router running interface eth1# ipv4-address 10.101.0.20/24
upstream_router running interface eth1# .. ..
upstream_router running vrf main# interface physical eth0
upstream_router running interface eth0# port pci-b0s4
upstream_router running interface eth0# ipv4-address 10.100.0.20/24
upstream_router running interface eth0# .. ..
upstream_router running vrf main# routing ipv4-route 10.200.0.0/24 next-hop 10.100.0.1 label 600
upstream_router running vrf main#

rt1

rt0> show mpls table
 Inbound Label  Type        Nexthop   Outbound Label
 -----------------------------------------------------
 600            SR-TE       10.125.0.2  1033/1044
 [..]

With multiple SR policies having a unique BSID, the isolation is guaranteed for MPLS traffic.

Triggered policies

The below drawing illustrates a topology involving multiple PEs connected with BGP. SR policies need to be implemented locally between each BGP node.

../../../../_images/srte_multi.svg

Using BGP triggered policies to ease segment routing policing

The use case depicts colored BGP routes; associated traffic needs to follow a defined SR policy relying on flex algorithm instead of the regular routing rules provided by the main SPF algorithm of the IGP.

Using the configurations proposed in Flex Algo Candidate-path configuration chapter will work, but will not be scalable from the configuration perspective.

The proposed solution relies on using a template policy. It consists of a policy indexed by color that includes a Flex Algorithm candidate path. When BGP receives a colored route with a given next hop, and that color matches the color of the policy-template, then a dynamic SR policy will be instantiated for the given next hop and color.

The below configuration is proposed:

rt1

rt1 running vrf main# routing segment-routing enabled true
rt1 running vrf main# routing segment-routing traffic-engineering
rt1 running traffic-engineering# flex-algorithm import isis instance 1
rt1 running traffic-engineering# triggered-policies policy-template color 5
rt1 running policy-template color 5# name for_color_5
rt1 running policy-template color 5# candidate-path 30 name fa129 type flex-algorithm algorithm 129
rt1 running policy-template color 5#