IOS XR 7.3.1 has been published in late February 2021 and is an ED version for many XR platforms including:
- NCS540: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5xx/release-notes/73x/b-release-notes-ncs540-r731.html
- NCS560: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs560/release-notes/73x/b-release-notes-ncs560-r731.html
- NCS5500: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/general/73x/release/notes/b-release-notes-ncs5500-r731.html
Software download for NCS5500:
We asked a few colleagues to help documenting the new improvements brought by the 7.3.1 version. It will be split in software innovations on one side (Segment Routing, SRv6, EVPN, Multicast, QoS, Security, …) and new supported hardware (chassis, power supply, new line cards and new fixed-form-factor products).
Segment Routing IPv6 (SRv6)
Jakub Horn presents and demonstrates in his lab:
- SRv6 uSID
- uSID config
- uSID ISIS config
- uSID BGP L3VPN config
- TI-LFA and uLoop Avoidance config
- Performance Measurement config
- FlexAlgo config
The configuration used for the demos are available here:
Jiri Chaloupka and Lampros Gkavogiannis detail the following features:
- EVPN Head-End
EVPN control plane used on top of the head-end to decide which interface is active or stand-by.
evpn interface PW-Ether 1 ethernet-segment identifier type 0 220.127.116.11.18.104.22.168.1 l2vpn xconnect group xc100 p2p evpn-headend interface PW-Ether1 neighbor evpn evi 1 target 1 source 1
- EVPN Convergence
- Fast ReRoute
Handled by the transport layer (SR TI-LFA for example)
- MAC Mobility
Available since EVPN inception, it uses a sequence number in the advertisement, to track VM move for example:
- Mass Withdraw
Also available since the early EVPN days. In this example, CE1 is multihomed so PE3 sees the mac addresses through the same segment ESI1.
PE1 losing the link to CE1, it just sends a RT1 update to PE3, that can reprogram the decision to send the traffic to PE2. But it takes a bit of time to generate, receive and compute this BGP advertisement. Hence the introduction of the next feature.
- Edge Failure Fast ReRoute
Similar to the L3VPN BGP PIC Edge feature, adapted for EVPN.
Using EBGP betwen CE and PE. PE1 will pre-program the back up path over PE2 that will forward via PE1 until the network fully converged. During that short period of time, we will have a sub-optimal routing path, but no packet loss.
And it works for both All-Active and Single-Active.
evpn interface Bundle-Ether100 ethernet-segment identifier type 0 22.214.171.124.126.96.36.199.01 convergence reroute
evpn interface Bundle-Ether100 ethernet-segment identifier type 0 188.8.131.52.184.108.40.206.01 load-balancing-mode single-active convergence reroute
- EVPN Load Balancing
Since the beginning we have All-Active mode where PE1 and PE2 are configured to make CE1 believe it’s connected to a single device via link aggregation.
Later, we introduced the single-active mode, followed by the port-active mode.
- SFA Single Flow Active
To improve the convergence, particularly when connected to legacy L2 protocols (like spanning-tree, REP-AG.G.8032), we introduce this new load balancing mode.
SFA is leveraging pre-programmed information between PE1 and PE2.
evpn interface Bundle-Ether100 ethernet-segment identifier type 0 220.127.116.11.18.104.22.168.01 load-balancing-mode single-flow-active convergence mac-mobility
Check https://datatracker.ietf.org/doc/html/draft-brissette-bess-evpn-l2gw-proto-06 for more details.
- Next-Hop Tracking for DF Election
We are enabling next-hop tracking for Route-Type 4. When NH disappears from the table, we trigger immediately a DF election.
evpn interface Bundle-Ether100 ethernet-segment identifier type 0 22.214.171.124.126.96.36.199.01 load-balancing-mode single-active convergence nexthop-tracking reroute
- NTP sync
When you have two nodes on the same ESI segment, and these two routers are NTP synchronized (no need for additional configuration). It will add the timestamps in the RT-4 and the whole convergence process will speed up.
- Multicast MultiHoming
This new feature enables redundancy for multi-attached multicast receivers. It leverages Route Type 7 and 8 for IGMP Synchronization between PEs. Also, it requires Designated Forwarder (DF) Election between these PE routers.
After IGMP snooping has been enabled and this information has been synced with the peer, both the peers need to act like a last hop router and send PIM join upstream. Once traffic arrives on both the peers, only one should forward it to the receiver. Designated Forwarder Election elects one peer to do the forwarding.
EVPN IPv4 MC Enhanced DF election for mcast: As per RFC 7432, designated forwarder (DF) election is at the granularity of <ESI,EVI> . However, customers need multi tenancy at finer level. A per multicast stream DF election is required, as they use a single Vlan for IPTV service
Quality of Service
Paban Sarma provides details on new QoS features:
- Shared-Policy Instances
The purpose is to get aggregated QoS value for customers owning multiple sub-interfaces over one given physical port. Example: Customer A paid for 5Gbps on 3 sub-interfaces and Customer B, they paid for 3Gbps over 2 sub-interfaces.
Limited to the same parent interface (physical or bundle) and is available for both ingress policers and egress queueing/shaper.
policy-map spi-in class class-default police rate 500 mbps ! ! end-policy-map ! policy-map spi-out class class-default shape average 500 mbps ! end-policy-map ! interface TenGigE0/0/0/16.1001 l2transport encapsulation dot1q 1001 service-policy input spi-in shared-policy-instance spi-1-in service-policy output spi-out shared-policy-instance spi-1-out ! interface TenGigE0/0/0/16.1002 l2transport encapsulation dot1q 1002 service-policy input spi-in shared-policy-instance spi-1-in service-policy output spi-out shared-policy-instance spi-1-out !
- Policy-map templates and uniqueness
This new feature is an enhancement of the unique policy-map scale.
Before IOS XR 7.3.1: each policy-map has an ID (total unique ID is 250): same policy map may be attached to different interface but only 250 unique ingress policy can exist on the system.
Starting with IOS XR 7.3.1 several policy-maps can share the same ID if they have:
Same classification (class-map name independent)
Same action policing (police rate independent)
Same marking action
policy-map P1-100M class class-default police rate 100 mbps ! set traffic-class 5 ! end-policy-map ! policy-map P2-1000M class class-default police rate 1000 mbps ! set traffic-class 5 ! end-policy-map
P1-100M and P2-1000M have the same classification, same action policing (even if it’s a policing at different rates) and same marking action: they are using the same ID and count for 1.
Before 7.3.1, we verify it uses two entries:
RP/0/RP0/CPU0:Router-721#show feature-mgr client qos-ea feature-info summary loc 0/0/CPU0 NPU DIR Lookup-type ACL-ID Refcnt Feature-Name --- --- -------------------- ------ ------ ------------ 0 IN L2_QOS 17 1 P1-100M:0 0 IN L2_QOS 18 1 P2-1000M:0 RP/0/RP0/CPU0:Router-721#
With 7.3.1, it’s only a single “feature-name”
RP/0/RP0/CPU0:Router-731#show feature-mgr client qos-ea feature-info summary loc 0/0/CPU0 NPU DIR Lookup-type ACL-ID Refcnt Feature-Name PolicyMap-Name --- --- -------------------- ------ ------ ------------------------------- -------------- 0 IN L2_QOS 10 2 32b51d8e63702738b16423f7e8df7be7 P1-100M P2-1000M RP/0/RP0/CPU0:Router-731#
For reference, let’s list a couple of examples that don’t share a common policy ID and count as 3 different entries:
policy-map P1-100M class class-default police rate 100 mbps ! set traffic-class 5 ! end-policy-map ! policy-map P2-1000M class class-default police rate 1000 mbps ! set traffic-class 3 ! end-policy-map ! policy-map P3-1000M class class-default police rate 1000 mbps ! set traffic-class 3 set cos 3 ! end-policy-map
Here, P1 and P2 are different, because setting different traffic-class values (3 and 5).
Also, P3 is different than P1 and P2, because it sets cos 3 (and not the others).
So, these 3 policy-maps are using 3 different IDs and are considered unique.
Rakesh Kandula presents the latest improvements in IOS XR security brought in IOS XR 7.3.1:
- SSD encryption (note: it’s limited to the platforms running XR7)
Feature developed for use-cases like: router theft, RMA scenario, unauthorized disk swap and router decommissionning.
Provides data-at-rest protection for sensitive data like running configuration Encryption key is generated in hardware TAm (Trust Anchor module) chip and is unique per line card in a chassis, it encrypts only a disk partition and not the entire SSD.
disk encryption activate location 0/x/CPU0
- X.509v3 Certificate based SSH authentication
This new feature will remove the need for Username/Password management (no need for RSA key management for end users): authenticate end users logging into routers using x.509v3 certificates (based on RFC6187).
Once local authentication passes, authorization can be local or remote (TACACS)
1- End user presents their certificate to the router for authentication
2- Router validates the certificate locally for authentication
3- Authorization request is then sent to TACACS server to fetch the group info of the user
4- User gets access to the router with the appropriate privilege level
RP/0/RP0/CPU0:5508-1-731(config)#ssh server algorithms host-key x509v3-ssh-rsa RP/0/RP0/CPU0:5508-1-731(config)#ssh server trustpoint host tp1 RP/0/RP0/CPU0:5508-1-731(config)#ssh server certificate username ? common-name user common name(CN) from subject name field user-principle-name user principle name(UPN) from subject alternate name RP/0/RP0/CPU0:5508-1-731(config)#ssh server certificate username
MPLS Segment Routing
This section is split itself in three parts
Jose Liste covers a lot of topics in this 30min long video:
- OSPF LFA/TI-LFA for FlexAlgo
Extends the benefits of TI-LFA to Flex-Algo. Automated Topology Independent and guaranteed sub-50ms per-prefix protection optimized per Flex-Algo.
Flex-Algo will run the shortest path computation for the primary and now also for the back-up path (and with OSPF). The back-up path is computed independantly.
In this example, the flex-algo 128 definition is “min IGP metric and avoid RED affinity”.
The support is now extended for OSPF at the level it was for ISIS:
- Rounding of Min-Delay Values
- OSPF Conditional Advertisement
- ISIS TI-LFA Protection of Unlabeled IPv6 Prefixes
- Inter-Level SRMS Advertisement Propagation
Performance Monitoring and Traffic-Engineering
- Named Profile
- SR Policy Delay Measurement with Loopback-mode
- SR Policy Liveless Monitoring
- SR-TE Cumulative-Metric Bound
Dynamic SR P2MP Policies
- Dynamic SR P2MP policies theory and lab demo
NCS57B1-6D24 / NCS57B1-5DSE