cs-sr-l3vpn-ncs540
Overview
Circuit-style Segment Routing (CS-SR) provides deterministic behaviour for routed traffic, making it particularly suitable for use cases that require persistent co-routed bidirectional paths, guaranteed bandwidth, and end-to-end path protection. The use cases we will be addressing here pertain to Utility WAN substation automation, encompassing L3 services from substation to control centre (SCADA data, CCTV, enterprise, etc.) and L2 services from substation to substation (Ethernet Teleprotection, L2 Utility protocols, e.g. GOOSE with stringent latency constraints) with CS-SR as part of the wider tutorial series. To flag off the series, let us start with CS-SR policy provisioning for L3VPN SCADA services.
Topology & Use Case
We are using a mix of routers across the NCS540 portfolio as the PEs and WAN core routers. We illustrate the L3VPN with CS-SR use case in this tutorial, leveraging a subset of the broader topology as depicted in the figure below.
| Nodes | Device Type | Software Version |
|---|---|---|
| PE1 | NCS 540 | IOS XR 7.9.1 |
| P2 | NCS 540 | IOS XR 7.9.1 |
| P3 | NCS 540 | IOS XR 7.9.1 |
| PE4 | NCS 540 | IOS XR 7.9.1 |
| CE1 | IR 8340 | IOS XE 17.12.1 |
| CE2 | ASR 1002 | IOS XE 17.9.3a |
To establish connectivity between the WAN substation and the control center, the CE IR8340 is deployed as a substation router connected to an RTU (Remote Terminal Unit), while the CE ASR-1002 headend router is connected to the control center. We will establish an L3VPN SCADA service between the endpoints.
Configuration
We will begin by configuring static CS-SR TE policy, followed by a brief overview of configuring a dynamic CS-SR policy. However, provisioning a feature-rich dynamic CS-SR policy deserves a separate tutorial, so we will defer that topic for future reference.
To configure static CS-SR TE policy, manual (persistent) adjacency SIDs need to be defined under the IGP interfaces. These adjacency SIDs will then constitute the explicit segment lists for the working and protect paths.
router isis 1008
...
address-family ipv4 unicast
...
interface TenGigE0/0/0/15
...
adjacency-sid absolute 15016
!
!
When configuring a static CS-SR policy, the first step involves defining the segment lists for each of the working and protect paths in both forward and backward directions. In the next snippet, we demonstrate the segment-list configuration for the working path at node PE1, while a similar process would be followed for the protect path.
segment-routing
global-block 16000 23999
traffic-eng
segment-list cs-working-bck
index 1 mpls label 15025
index 2 mpls label 15016
!
segment-list cs-working-fwd
index 1 mpls label 15016
index 2 mpls label 15025
!
!
!
Next, we proceed to define the SR policy at PE1. The color attribute is assigned to the policy end-point IP i.e. loopback IP of PE4. path-protection command enables end-to-end candidate path protection. This is followed by configuration of the candidate-paths, namely the working path & the protect path. The working path is assigned a higher preference to establish it as the active path, while the protect path serves as the backup path, ready to take over in the event of failures. We also configure a lock timer for the protect path. This ensures that in case of a failure and subsequent recovery of the working path, the working path will revert back to being the active path once the lock duration elapses.
segment-routing
traffic-eng
policy srte_1_ep_5.5.5.5
color 1 end-point ipv4 5.5.5.5
path-protection
!
candidate-paths
preference 50
explicit segment-list cs-protect-fwd
reverse-path segment-list cs-protect-bck
!
lock
duration 30
!
!
preference 100
explicit segment-list cs-working-fwd
reverse-path segment-list cs-working-bck
!
!
!
One might wonder, “Why set up the reverse path at PE1 if the forward path is already defined at PE4?” However, the reverse-path config holds significance here in the context of SR-PM (Segment-Routing Performance-Measurement) liveness probes, that are needed to trigger path protection. By configuring the reverse-path, we ensure that the PM probes packets carry the labels in both the forward and reverse direction, thereby guaranteeing a robust path protection mechanism.
SR-PM plays a pivotal role in the CS-SR TE solution by ensuring proper detection of candidate path liveness and thereby enabling effective path protection. Without proper SR-PM, path protection will not be triggered if the failure in the CS-SR policy candidate path does not occur at the first hop in the segment list since the headends (here PE1 & PE4) do not validate past the first SID.
We create a liveness profile for both the working and protect paths, as depicted below.
segment-routing
traffic-eng
policy srte_1_ep_5.5.5.5
performance-measurement
liveness-detection
liveness-profile backup name protect
liveness-profile name working
!
!
!
!
!
For each of the working and protect paths, we define the liveness probe transmission interval and the detect-multiplier, combining which the failure detection window is determined.
performance-measurement
liveness-profile sr-policy name protect
probe
tx-interval 30000
measurement-mode loopback
!
liveness-detection
multiplier 3
!
!
liveness-profile sr-policy name working
probe
tx-interval 30000
measurement-mode loopback
!
liveness-detection
multiplier 3
!
!
!
Starting IOS XR release 7.10.1, we will support hardware offload for SR-PM probing functionality. This enhancement will significantly increase the probing frequency, enabling us to achieve fast failure detection followed by rapid convergence in < 50ms. We will revisit this feature when we delve into the Ethernet Teleprotection use case that imposes stringent latency constraints.
For now, let us look at how we verify the CS-SR policy.
RP/0/RP0/CPU0:PE1#sh segment-routing traffic-eng policy detail
Thu Jun 22 09:34:27.695 UTC
SR-TE policy database
---------------------
Color: 1, End-point: 5.5.5.5
Name: srte_c_1_ep_5.5.5.5
Status:
Admin: up Operational: up for 6d03h (since Jun 16 06:02:55.845)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: srte_1_ep_5.5.5.5
Requested BSID: dynamic
Constraints:
Protection Type: protected-preferred
Maximum SID Depth: 12
Performance-measurement:
Reverse-path Label: Not Configured
Delay-measurement: Disabled
Liveness-detection: Enabled
Profile: working
Invalidation Action: down
Logging:
Session State Change: No
Statistics:
...
Explicit: segment-list cs-working-fwd (valid)
Reverse: segment-list cs-working-bck
Weight: 1, Metric Type: TE
SID[0]: 15016 [Adjacency-SID, 108.12.53.12 - 108.12.53.53]
SID[1]: 15025
Reverse path:
SID[0]: 15025
SID[1]: 15016
Protection Information:
Role: WORKING
Path Lock: Timed
Lock Duration: 300(s)
State: ACTIVE
Preference: 50 (configuration) (protect)
Name: srte_1_ep_5.5.5.5
Requested BSID: dynamic
Constraints:
Protection Type: protected-preferred
Maximum SID Depth: 12
Performance-measurement:
Reverse-path Label: Not Configured
Delay-measurement: Disabled
Liveness-detection: Enabled
Profile: protect
Invalidation Action: down
Logging:
Session State Change: No
Statistics:
...
Explicit: segment-list cs-protect-fwd (valid)
Reverse: segment-list cs-protect-bck
Weight: 1, Metric Type: TE
SID[0]: 15017 [Adjacency-SID, 108.12.54.12 - 108.12.54.54]
SID[1]: 15014
Reverse path:
SID[0]: 15014
SID[1]: 15017
Protection Information:
Role: PROTECT
Path Lock: Timed
Lock Duration: 30(s)
State: STANDBY
LSPs:
LSP[0]:
LSP-ID: 11 policy ID: 2 (active)
Local label: 24007
State: Programmed
Binding SID: 24015
Performance-measurement:
Reverse-path Label: Not Configured
Delay-measurement: Disabled
Liveness-detection: Enabled
Profile: working
Invalidation Action: down
Logging:
Session State Change: No
Session State: up, for 3d01h (since Jun 19 08:00:31.750)
LSP[1]:
LSP-ID: 12 policy ID: 2 (standby)
Local label: 24011
State: Standby programmed state
Performance-measurement:
Reverse-path Label: Not Configured
Delay-measurement: Disabled
Liveness-detection: Enabled
Profile: protect
Invalidation Action: down
Logging:
Session State Change: No
Session State: up, for 6d03h (since Jun 16 06:02:55.991)
Attributes:
Binding SID: 24015
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
Max Install Standby Candidate Paths: 0
Next, we look at the more sophisticated alternative, the dynamic CS-SR TE policy provisioning on the same topology. The headend routers PE1 and PE4 utilize the PCEP protocol to request path from the PCE, specifying bandwidth requirements and path constraints. The stateful PCE has a centralized real-time view of the network (through BGP-LS) that it leverages to compute the path. It then encodes the path in a list of adjacency SIDs and responds to the headend routers over the same PCEP session.
segment-routing
traffic-eng
policy srte_1_ep_5.5.5.5
candidate-paths
preference 100
dynamic
pcep
!
metric
type igp
!
!
constraints
segments
protection unprotected-only
adjacency-sid-only
!
disjoint-path group-id 3 type node
!
bidirectional
co-routed
association-id 1100
router bgp 110
bgp router-id 1.1.1.1
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor 3.3.3.3
remote-as 110
update-source Loopback0
address-family ipv4 unicast
!
address-family vpnv4 unicast
next-hop-self
!
!
vrf SCADA_RAW_SOCKET
rd 803:1
address-family ipv4 unicast
redistribute connected
!
neighbor 15.15.15.2
remote-as 803
ebgp-multihop 2
update-source GigabitEthernet0/0/0/8.103
address-family ipv4 unicast
route-policy policy-SR-policy in
route-policy PASS_ALL out
next-hop-self
!
!
!
!
Leave a Comment