COE-PCE Initiated SR Policy with OSPF Autoroute Announce
Feature Name |
Release Information |
Feature Description |
---|---|---|
PCE Initiated SR Policy with OSPF Autoroute Announce |
Cisco IOS XE Bengaluru 17.4.1 |
This feature enables a steering mechanism in which IGPs automatically use the policy for destination's downstream of the policy end point. |
A PCE collects various pieces of network information to determine traffic flows causing link congestion. The PCE computes a suitable path to divert those flows and to alleviate the congestion. The PCE then deploys the SR-TE policy to divert the traffic leading to the congestion using the Stateful Path Computation Element Protocol (PCEP) to provision the policy. When the congestion is alleviated, the SR-TE policy is removed.
The PCEP message contains SID list to be deployed by the head-end. Path Computation Client (PCC) profiles allow activation of autoroute announce for the policy provisioned by PCEP, using the profile IDs. The profile ID on the PCE and PCC should match, otherwise the policy is not provisioned. For example, if the PCE provisions a policy with profile ID 1 and the head-end where the policy is being provisioned also has the PCC profile ID 1 configured with autoroute announce, COE-PCE initiated SR policy is activated for that policy.
COE-PCE Initiated SR Policy
The preceding topology shows how an SR-PCE policy is initiated from COE:
-
SR policy is configured on the COE with profile ID.
-
COE pushes the SR policy to PCE and PCE forwards the SR policy to PCC.
-
Profile ID on PCC is matched with the profile ID on COE-PCE.
-
OSPF autoroute announce is configured on the PCC.
-
The policy gets provisioned.
-
The data traffic now adheres to the SR policy that is pushed from the COE.
-
Complete SR Policy manipulation occurs only on COE.
Restrictions for PCE Initiated SR Policy
-
A maximum of 500 SR policies are supported.
-
Only native COE is supported.
-
Effective Cisco IOS XE Bengaluru 17.5.1, Bandwidth optimization based on SR tactical policy is supported on RSP3.
-
Bandwidth optimization by using COE is not supported.
-
PIC core and PIC edge are not supported over SR-TE tunnel till Cisco IOS XE Cupertino Release 17.8.1. Starting with Cisco IOS XE Release 17.9.1, PIC core is supported for short LCM policies with 0, 1, or 2 SR labels.
-
Effective Cisco IOS XE Bengaluru 17.5.1, ECMP over SR-TE is supported on RSP3.
-
6PE and 6VPE are not supported with three and four transport labels.
-
IPv6 is not supported.
-
A maximum of 10,000 VPNv4 prefix limits are supported.
-
BGP LU (RFC 3107) is not supported for intra-AS and inter-AS.
ECMP Over SR-TE
Feature Name |
Release Information |
Feature Description |
---|---|---|
ECMP over SR-TE Policy |
Cisco IOS XE Bengaluru 17.5.1 |
This feature allows you to configure ECMP over SR-TE policies. In case of multiple paths, this feature enables mitigation of local congestion through load balancing. This feature is supported only on Cisco ASR 900 RSP3 module. |
The following sections explain how local congestion can be mitigated and how ECMP can be deployed over SR-TE policies to attain load balancing.
Note |
The traffic that is load balanced over multiple paths is HW-load balanced. |
Restrictions for ECMP over SR-TE Policies
Cisco ASR 900 RSP3 module supports sr_5_label_push_enable and sr_pfp_enable templates. Following restrictions apply for different template combinations.
With sr_5_label_push_enable template:
-
Only one service label is supported with LB over SR-TE tunnels with three or four TE labels. This service label includes L3VPN, L2VPN, 6PE, 6VPE, and RFC 3107 BGP-LU label.
-
6PE and 6VPE are not supported with three and four SR-TE tunnel labels.
-
Segment routing is not supported in enable_portchannel_qos_multiple_active template.
-
HW load balancing for L2VPN/EVPN services is not supported if the L2VPN/EVPN destination has a static route configured over SR-TE tunnel.
With sr_pfp_enable template:
-
SR PM HW time stamping is not supported.
-
VLAN COS marking is not supported.
-
HW load balancing is not supported.
-
Policer based hierarchical QOS on the ingress is not supported.
-
Short-Pipe tunneling mode is not supported.
Other Restrictions:
-
PIC core over SR-TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.8.1.
-
PIC edge over SR TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.8.1.
-
PIC edge multipath over SR TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.9.1.
-
W-ECMP is not supported.
-
Next hop ECMP is not supported within an SR policy.
-
Local congestion mitigation (LCM) is applicable only for best effort traffic. All other delay sensitive traffic uses safe SIDs (Flex Algo 128). Delay sensitive traffic is not redirected using the LCM tunnels.
Local Congestion Mitigation
In today’s network deployments it is important for every router in the network to have the capability to provision the traffic in such a way that it avoids the congestion based on the amount of traffic ingressing and egressing out of it. In order to provision this congestion mitigation, it is essential for the routers to support Equal Cost Multi-Path (ECMP) load balancing, that is, distributing the traffic based on the number of paths available to reach the destination.
Congestion mitigation helps the routers to move certain traffic to a different path than the current path, using the tactical SR policies. When the link congestion threshold is crossed, the COE (Cisco Optimization Engine) that monitors the link congestion based on the interface counters, pushes these tactical policies using PCE. These PCE initiated tactical policies that are used for local congestion mitigation (LCM) are deployed when necessary and only best effort traffic is load balanced over these tactical SR-TE policies.
In the above topology, let us assume that the best effort traffic is coming in to P1 from PE1 and PE2 for the destination PE3 and the link between P1 and PE3 is congested. To mitigate the congestion between P1 and PE3, ECMP paths from P1 and PE3 are required. With segment routing this is achieved by deploying multiple tactical SR policies from P1 to PE3, one through directly connected link P1-PE3 and the other through the path P1-PE4-PE3. These policies are called tactical policies and are used to avoid local congestion mitigation by load balancing the best effort traffic over these tactical policies. The LCM is applicable only for best effort traffic. All other delay sensitive traffic would use safe SIDs (Flex Algo 128). Delay sensitive traffic is not redirected using the LCM tunnels. Originating traffic is directed on non-LCM tunnels and transiting traffic with safe-SIDs is treated as normal label entry traffic and forwarded accordingly.
In the above topology, any node may deploy LCM tactical tunnels to mitigate congestion over a particular link. These nodes transit or sometimes originate the traffic to the LCM tunnel end points or even beyond the tunnel end points.
Let us assume that PE nodes originate the traffic and P nodes are transit node for the traffic originated somewhere else. Based on these combinations following are the different types of traffic that have to be considered:
As a PE Node,
-
L3VPN best effort traffic
-
L2VPN best effort traffic
-
Global traffic
As a P node,
-
Any traffic that comes in for a non-flexible algorithm 0 label is treated as an entry swap on the Label lookup.
-
Any traffic that comes in for flexible algorithm 0 label is treated as a swap case or it may be translated to pop and push stack of labels, if there is an LCM created for that outgoing link based on congestion.
Based on the number of TE labels that the LCM tunnels have to push, the number of labels outside of TE labels can be either one or two (service labels).
Load Balancing
At the head end, following are the different types of traffic that is subjected to load balancing. The traffic type here includes both best effort and delay sensitive.
As a PE Node,
-
L3VPN traffic
-
L2VPN traffic
-
Global traffic
As a P node,
-
Any traffic that comes in is treated based on the Label lookup.
Autoroute Announcement
Autoroute announcement or bandwidth optimization is used to steer traffic away from congested links and better utilize the network.
The PCEP message contains SID list to be deployed by the head-end. Path Computation Client (PCC) profiles allow autoroute announce to be activated for the policy instantiated by PCEP, using the profile IDs. For example, if the PCE instantiates a policy with profile ID 1 and the head-end where the policy is being instantiated has the PCC profile ID 1 configured with autoroute announce, PCE initiated SR policy is activated for that policy.
Autoroute announce can be configured under both policies created with strict SID and policies created with non-strict SID. The main difference between configuring autoroute under policies created with strict SID (assume A) and non-strict SID (assume B) is that with A, the lookup entry will be programmed only in RIB whereas with B, the lookup entry will be programmed in RIB and LFIB for flexible algorithm label 0.
Static Route Configuration
By adding a static route to the same destination but with different tunnels having the same endpoint, a load balancing is formed for the route over the tunnels configured. This is applicable for all types of traffic.
Next Hop ECMP within a SR Policy
If there is a SR policy created to a destination with a set of SIDs and the SR policy headend have multiple equal paths to reach the next hop, no ECMP is formed to reach the next hop within the SR policy.
Configuring ECMP over SR-TE Policy with OSPF Autoroute Announce
The below configuration shows how to configure ECMP over SR-TE policy with OSPF autoroute announce and PCE initiated segement routing policy with profile ID as 100.
pce
address ipv4 13.13.13.13
segment-routing traffic-eng
peer ipv4 10.0.0.1
segment-list name ss1
index 1 mpls label 18021
index 2 mpls label 18023
policy 100
binding-sid mpls 15999
color 100 end-point ipv4 12.12.12.12
candidate-paths
preference 10
explicit segment-list ss1
!
constraints
segments
dataplane mpls
profile-id 100
Now, to push the PCE initiated OSPF autoroute announce from PCE to PCC, the profile IDs on PCE and PCC must match. The below configuration shows the PCC configuration and that the profile ID is matching with PCE and thus the autoroute announce is enabled. Based on the number of autoroute policies configured on the ECMP link, packets are load balanced on the ECMP links for the non-strict SIDs.
segment-routing traffic-eng
pcc
pce address 13.13.13.13 source-address 10.0.0.1
profile 100
autoroute
include all
Verifying SR Policy with Autoroute Announce
ASR903-R1#show segment-routing traffic-eng policy all
Name: *12.12.12.12|100 (Color: 100 End-point: 12.12.12.12)
Owners : PCEP
Status:
Admin: up, Operational: up for 66:41:16 (since 09-18 16:56:50.444)
Candidate-paths:
Preference 10 (PCEP):
PCC profile: 100
Dynamic (pce 13.13.13.13) (active)
Metric Type: TE, Path Accumulated Metric: 5
16003 [Prefix-SID, 3.3.3.3]
16012 [Prefix-SID, 12.12.12.12]
Attributes:
Binding SID: 15999
Allocation mode: explicit
State: Programmed
Autoroute:
Include all
Verifying OSPF Autoroute for IGP
Use the following two commands to verify the OSPF Autoroute for IGP:
ASR903-R1#show ip cef 12.12.12.12 -------------IGP ROUTE
12.12.12.12/32
nexthop 12.12.12.12 Tunnel65536 ------------Tunnel pushed for IGP ROUTE
ASR903-R1# show ip cef 12.12.12.12 internal
12.12.12.12/32, epoch 3, RIB[I], refcnt 6, per-destination sharing
sources: RIB
feature space:
IPRM: 0x00028000
Broker: linked, distributed at 1st priority
LFD: 12.12.12.12/32 0 local labels
contains path extension list
ifnums:
Tunnel65536(64)
path list 3C97B678, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
path 3E393010, share 1/1, type attached nexthop, for IPv4
MPLS short path extensions: [rib | lblmrg | srlbl] MOI flags = 0x1 label implicit-null
nexthop 12.12.12.12 Tunnel65536, IP midchain out of Tunnel65536 2FFE3D00
output chain:
IP midchain out of Tunnel65536 2FFE3D00
label [16012|16012]
FRR Primary (0x3D9D4CE0)
<primary: TAG adj out of Port-channel1, addr 100.0.0.2 3C9559C0>
<repair: TAG adj out of BDI1110, addr 111.0.0.2 3C954FC0>
Verify the Tunnel ID on the SR Policy
ASR903-R1# show segment-routing traffic-eng policy name margin detail
Name: Margin (Color: 1000 End-point: 12.12.12.12)
Owners : CLI
Status:
Admin: up, Operational: up for 00:50:52 (since 09-16 11:00:06.697)
Candidate-paths:
Preference 10 (CLI):
Dynamic (pce 13.13.13.13) (active)
Metric Type: TE, Path Accumulated Metric: 5
16012 [Prefix-SID, 12.12.12.12]
Attributes:
Binding SID: 15900
Allocation mode: explicit
State: Programmed
IPv6 caps enabled
Tunnel ID: 65536 (Interface Handle: 0x15B)
Per owner configs:
CLI
Binding SID: 15900
Stats:
Packets: 535473 Bytes: 805338440
Event history:
Timestamp Client Event type Context: Value
--------- ------ ---------- -------: -----
09-16 11:00:06.377 CLI Policy created Name: CLI
09-16 11:00:06.418 CLI Set colour Colour: 1000
09-16 11:00:06.418 CLI Set end point End-point: 12.12.12.12
09-16 11:00:06.446 CLI Set binding SID BSID: Binding SID set
09-16 11:00:06.577 CLI Set dynamic Path option: dynamic
09-16 11:00:06.620 CLI BSID allocated FWD: label 15900
09-16 11:00:06.637 FH Resolution Policy state UP Status: PATH RESOLVED
09-16 11:00:06.697 FH Resolution Policy state DOWN Status: PATH NOT RESOLVED
09-16 11:00:06.706 CLI Set dynamic pce Path option: dynamic pce
09-16 11:00:07.240 FH Resolution Policy state UP Status: PATH RESOLVED
09-16 11:00:09.520 FH Resolution REOPT triggered Status: REOPTIMIZED