SR OS 13.0.R10 Software Release Notes PDF

Alcatel-Lucent
Service Router | Release 13.0.R10

SR OS Software Release Notes | June 2016
3HE09898 0010 TQZZA Edition 01
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners.
The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2016 Alcatel-Lucent
All Rights Reserved.
Table of Contents
Table of Contents
About this Document....................................................................................................................... 1
Release 13.0.R10 Documentation Set ............................................................................................ 2

Release 13.0.R10 Supported Hardware ......................................................................................... 4
Supported Chassis Configurations ...............................................................................................................4
Supported Cards (SFM, CPM, XCM, CCM, CFM, MCM, IOM, IMM, ISM)...................................................5
Supported Adapters (XMA, MDA, ISA, CMA, VSM) ...................................................................................16
New Features ................................................................................................................................. 26

Release 13.0.R10.......................................................................................................................................26
Release 13.0.R9 .........................................................................................................................................26
Release 13.0.R8 .........................................................................................................................................28
Release 13.0.R7 .........................................................................................................................................28
Release 13.0.R6 .........................................................................................................................................29
Release 13.0.R5 .........................................................................................................................................31
Release 13.0.R4 .........................................................................................................................................33
Release 13.0.R3 .........................................................................................................................................51
Release 13.0.R2 .........................................................................................................................................51
Release 13.0.R1 .........................................................................................................................................51
Enhancements ............................................................................................................................... 77
Release 13.0.R10.......................................................................................................................................77
Release 13.0.R9 .........................................................................................................................................77
Release 13.0.R8 .........................................................................................................................................78
Release 13.0.R7 .........................................................................................................................................79
Release 13.0.R6 .........................................................................................................................................80
Release 13.0.R5 .........................................................................................................................................83
Release 13.0.R4 .........................................................................................................................................84
Release 13.0.R3 .........................................................................................................................................93
Release 13.0.R2 .........................................................................................................................................95
Release 13.0.R1 .........................................................................................................................................96
Limited Support Features and Enhancements ......................................................................... 106
Unsupported Features ................................................................................................................ 107

Hardware ..................................................................................................................................................107
System......................................................................................................................................................108
Quality of Service ....................................................................................................................................109
Routing .....................................................................................................................................................109
MPLS ........................................................................................................................................................110
Services ....................................................................................................................................................110
Subscriber Management ..........................................................................................................................111
Application Assurance ..............................................................................................................................112
Deprecated Features ................................................................................................................... 113

Release 13.0.R10.....................................................................................................................................113
Release 13.0.R9 .......................................................................................................................................113
Release 13.0.R8 .......................................................................................................................................113
SR OS 13.0.R10 Software Release Notes

Table of Contents
Release 13.0.R7 .......................................................................................................................................113

Release 13.0.R6 .......................................................................................................................................113
Release 13.0.R5 .......................................................................................................................................113
Release 13.0.R4 .......................................................................................................................................113
Release 13.0.R3 .......................................................................................................................................113
Release 13.0.R2 .......................................................................................................................................114
Release 13.0.R1 .......................................................................................................................................114
Changed or Deprecated Commands.......................................................................................... 115

Release 13.0.R10.....................................................................................................................................115
Release 13.0.R9 .......................................................................................................................................115
Release 13.0.R8 .......................................................................................................................................115
Release 13.0.R7 .......................................................................................................................................115
Release 13.0.R6 .......................................................................................................................................116
Release 13.0.R5 .......................................................................................................................................116
Release 13.0.R4 .......................................................................................................................................116
Release 13.0.R3 .......................................................................................................................................118
Release 13.0.R2 .......................................................................................................................................118
Release 13.0.R1 .......................................................................................................................................118
Usage Notes ................................................................................................................................. 135
Software Upgrade Procedures ................................................................................................... 151

Software Upgrade Notes ..........................................................................................................................151
AA Signatures Upgrade Procedure ..........................................................................................................156
ISSU Upgrade Procedure .........................................................................................................................161
Standard Software Upgrade Procedure ...................................................................................................174
Known Limitations....................................................................................................................... 178

Resolved Issues........................................................................................................................... 231
Release 13.0.R10.....................................................................................................................................231
Release 13.0.R9 .......................................................................................................................................234
Release 13.0.R8 .......................................................................................................................................237
Release 13.0.R7 .......................................................................................................................................241
Release 13.0.R6 .......................................................................................................................................245
Release 13.0.R5 .......................................................................................................................................250
Release 13.0.R4 .......................................................................................................................................255
Release 13.0.R3 .......................................................................................................................................263
Release 13.0.R2 .......................................................................................................................................268
Release 13.0.R1 .......................................................................................................................................271
Known Issues............................................................................................................................... 276
Change History for Release 13.0 Release Notes ...................................................................... 287

Technical Support ....................................................................................................................... 289

List of Tables
List of Tables
Table 1. Release 13.0.R10 Documentation Set ................................................................................................2
Table 2. Supported 7950 XRS Chassis Configurations .....................................................................................4
Table 3. Supported 7750 SR and 7450 ESS Chassis .......................................................................................4
Table 4. SFM, CPM, CCM, and XCM Cards Supported in 7950 XRS...............................................................5
Table 5. SFM, CPM, CFM, MCM, CCM, IOM, IMM, and ISM Cards Supported in 7750 SR.............................5
Table 6. SFM, CPM, IOM, IMM, and ISM Cards Supported in 7450 ESS in Non-Mixed Mode.......................10
Table 7. IOM, IMM, and ISM Cards Supported in the 7450 ESS in Mixed Mode ............................................14
Table 8. XMAs and C-XMAs Supported in 7950 XRS .....................................................................................16
Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR ................................................................................17
Table 10. MDAs, ISAs, and VSMs Supported in 7450 ESS in Non-Mixed Mode ...........................................20
Table 11. MDAs, ISAs, and VSMs Supported in the 7450 ESS in Mixed Mode ..............................................23
Table 12. Features Added Earlier than Release 13.0.R10 ..............................................................................26
Table 13. Additional Hardware Assemblies with 1G Port IEEE 1588 Port-Based Timestamping Capability...28
Table 14. Additional Hardware with IEEE 1588 Port-Based Timestamping Capability ...................................30
Table 15. 7750 SR-a4/a8 with IEEE 1588 Port-Based Timestamping Capability............................................32
Table 18. New and Updated AA Protocols in Release 13.0.R5.......................................................................84
Table 22. New and Updated AA Protocols in Release 13.0.R1.....................................................................105
Table 23. Unsupported Hardware Features ..................................................................................................107
Table 24. Unsupported System Features ......................................................................................................108
Table 25. Unsupported QoS Features ...........................................................................................................109
Table 26. Unsupported Routing Features......................................................................................................109
Table 27. Unsupported MPLS Features ........................................................................................................110
Table 28. Unsupported Services Features ....................................................................................................110
Table 29. Unsupported Subscriber Management Features...........................................................................111
Table 30. Unsupported AA Features .............................................................................................................112
Table 31. Compatible 7750 SR IOMs and IMMs for MS-ISA/MS-ISA2 Applications ....................................135
Table 32. Compatible 7450 ESS IOMs and IMMs for MS-ISA/MS-ISA2 Applications...................................136
Table 33. Compatible 7450 ESS Mixed Mode IOMs and IMMs for MS-ISA/MS-ISA2 Applications ..............137
Table 34. Compatible Devices for dynamic LAN-to-LAN IPsec Tunnels ......................................................146
Table 35. Compatible IPsec Soft Client ........................................................................................................146
Table 36. BFD VCCV Interoperability with Juniper MX .................................................................................148
Table 37. Nuage VSD and SR OS Node XMPP Compatibility ......................................................................148
Table 38. Nuage VSP and SR OS Node EVPN Compatibility .......................................................................149
Table 39. ATM MDAs that Support Access Mode Only .................................................................................186
Table 40. Issues Resolved Earlier than Release 13.0.R10 ...........................................................................234
Table 41. Change History ..............................................................................................................................287

About this Document
About this Document

This document provides an overview of SR OS in Release 13.0.R10 for the 7450 Ethernet
Service Switch (ESS), 7750 Service Router (SR), and 7950 eXtensible Routing System (XRS)
platforms.
In this document, the terms “SR OS node” and “SR OS chassis” refer to the 7450 ESS, 7750
SR, and 7950 XRS platforms.
Note:
Unless otherwise stated, the term “ISA” refers to any of the following hardware assemblies:
• MS-ISA/MS-ISA-E MDAs (for example, the 7750 SR/7450 ESS Multiservice ISA)
• MS-ISM/MS-ISM-E
• any IMMs containing MS-ISA2/MS-ISA2-E cards (for example, 7x50 MS-ISA2 + 1-
port 100GE CFP IMM – L3BQ)
• MS-ISA2 and MS-ISA2-E in IOM4-e
SR OS 13.0.R10 Software Release Notes 1

Release 13.0.R10 Documentation Set

The SR OS Release 13.0.R10 documentation set consists of Release Notes and the 7450 ESS,
7750 SR, and 7950 XRS user guides. The components of the Release 13.0.R10 documentation
set are listed in Table 1. New guides are printed in bold.
Table 1. Release 13.0.R10 Documentation Set
Document title Platform Part number

SR OS 13.0.R10 Software Release Notes 7450 ESS 3HE09898 0010 TQZZA 01
7750 SR
7950 XRS
13.0 AA Protocols and Applications for the 7450 ESS 3HE 10507 AAAA TQZZA
7450 ESS and 7750 SR 7750 SR
Advanced Configuration Guide for 7450 ESS, 7450 ESS 3HE 10564 AAAA TQZZA
7750 SR and 7950 XRS for Releases up to 7750 SR
13.0.R6 - Part I
7950 XRS
Advanced Configuration Guide for 7450 ESS, 7450 ESS 3HE 10565 AAAA TQZZA
7750 SR and 7950 XRS for Releases up to 7750 SR
13.0.R6 - Part II
7950 XRS
Basic System Configuration Guide 7450 ESS 3HE09844 AAAB TQZZA
7750 SR 3HE09826 AAAB TQZZA
7950 XRS 3HE09861 AAAB TQZZA
Interface Configuration Guide 7450 ESS 3HE09845 AAAB TQZZA
Gx AVPs Reference Guide 7750 SR 3HE09828 AAAB TQZZA
Layer 2 Services and EVPN Guide: VLL, 7450 ESS 3HE09847 AAAB TQZZA
VPLS, PBB, and EVPN 7750 SR 3HE09829 AAAB TQZZA
Layer 3 Services Guide: Internet Enhanced 7450 ESS 3HE09848 AAAB TQZZA
Services and Virtual Private Routed Net- 7750 SR 3HE09830 AAAB TQZZA
work Services
MPLS Guide 7450 ESS 3HE09849 AAAB TQZZA
Multiservice Integrated Service Adapter Guide 7450 ESS 3HE09832 AAAB TQZZA
7750 SR
OAM and Diagnostics Guide 7450 ESS 3HE09850 AAAB TQZZA
2 SR OS 13.0.R10 Software Release Notes

Table 1. Release 13.0.R10 Documentation Set (Continued)
Document title Platform Part number

Quality of Service Guide 7450 ESS 3HE09851 AAAB TQZZA
RADIUS Attributes Reference Guide 7750 SR 3HE09835 AAAB TQZZA
Router Configuration Guide 7450 ESS 3HE09853 AAAB TQZZA
Routing Protocols Guide 7450 ESS 3HE09854 AAAB TQZZA
Services Overview Guide 7450 ESS 3HE09855 AAAB TQZZA
System Management Guide 7450 ESS 3HE09856 AAAB TQZZA
Triple Play Service Delivery Architecture 7450 ESS 3HE09857 AAAB TQZZA
Guide 7750 SR 3HE09840 AAAB TQZZA
Versatile Service Module Guide 7750 SR 3HE09841 AAAB TQZZA
Zipped collection of documents 7450 ESS 3HE09860 AAAB TQZZA

Release 13.0.R10 Supported Hardware

The following tables summarize the hardware supported in SR OS Release 13.0.R10. New
hardware supported since SR OS Release 12.0.R1 is printed in bold.
Supported Chassis Configurations
Table 2. Supported 7950 XRS Chassis Configurations
Alcatel-Lucent
Model # Description
7950 XRS-16c A single 33RU chassis that holds up to 8 XCMs and 16 C-XMAs
7950 XRS-20 A single 48RU chassis that holds up to 10 XCMs and 20 XMAs or C-XMAs
7950 XRS-40 Contains two (2) XRS-20 chassis that hold up to 40 XMAs
Table 3. Supported 7750 SR and 7450 ESS Chassis
Alcatel-Lucent
Model # Description
7750 SR-1e 7750 SR-1e chassis (AC and DC)
7750 SR-7 7750 SR-7 chassis (AC and DC)
7750 SR-12 7750 SR-12 chassis (AC and DC)
7750 SR-12e 7750 SR-12e integrated chassis
7750 SR-a4 7750 SR-a4 chassis (AC and DC)
7750 SR-a8 7750 SR-a8 chassis (AC and DC)
7750 SR-c4 7750 SR-c4 chassis (AC and DC)
7750 SR-c12 7750 SR-c12 chassis (AC and DC)
7450 ESS-6 7450 ESS-6 chassis (AC and DC)
7450 ESS-6v 7450 ESS-6v chassis (vertical ESS-6)

Supported Cards (SFM, CPM, XCM, CCM, CFM, MCM, IOM, IMM,
ISM)
The following tables summarize the Switch Fabric/Control Processor Modules (SF/CPMs,
CPMs, or SFMs), XMA Control Modules (XCMs), Connection and Control Modules (CCMs),
Control and Forwarding Modules (CFMs), MDA Carrier Modules (MCMs), Chassis Control
Modules (CCMs), Input/Output Modules (IOMs), Integrated Media Modules (IMMs), and
Integrated Services Modules (ISMs) supported in SR OS Release 13.0.R10.
Table 4. SFM, CPM, CCM, and XCM Cards Supported in 7950 XRS
Alcatel-Lucent
Part # Description
3HE06936AA 7950 XRS-20 XMA Control Module (XCM-X20)
3HE07115AA 7950 XRS-20 Switch Fabric Module (SFM-X20)
3HE07116AA 7950 XRS-20 Control Processor Module (CPM-X20)
3HE07117AA 7950 XRS-20 Connection and Control Module (CCM-X20)
3HE08021AA 7950 XRS-20 Switch Fabric Module B (SFM-X20-B)
3HE08120AA 7950 XRS-16c Switch Fabric Module (SFM-X16)
3HE08121AA 7950 XRS-16c Control Processor Module (CPM-X16)
3HE08125AA 7950 XRS-16c XMA Control Module (XCM-X16)
3HE08505AA 7950 XRS-20 Standalone Switch Fabric Module B (SFM-X20S-B)
3HE09280AA 7950 XRS-16c XCM with XMA support
Table 5. SFM, CPM, CFM, MCM, CCM, IOM, IMM, and ISM Cards Supported in
7750 SR
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE00020AB 7750 SR 20G Input Output Module (IOM)
✓ ✓
Baseboard (iom-20g-b)
3HE01170AA 7750 SR 400G SF/CPM2 ✓ ✓
3HE01171AA 7750 SR 200G SF/CPM2 ✓
3HE01473AA 7750 SR 20G Input Output Module (IOM2)
✓ ✓
Baseboard (iom2-20g)
3HE03607AA 7750 SR-c12 CFM-XP ✓
3HE03608AA 7750 SR-c4/c12 MCM-XP 1 ✓
3HE03617AA 7750 SR-12 SF/CPM3 ✓ ✓
3HE03619AA 7750 SR IOM3-XP (iom3-xp) ✓ ✓ ✓
3HE03622AA 7750 SR 4-port 10GE XFP IOM (IMM) ✓ ✓
3HE03623AA 7750 SR 8-port 10GE XFP IOM (IMM) ✓ ✓
3HE03624AA 7750 SR 48-port GE SFP IOM (IMM) ✓ ✓ ✓

7750 SR (Continued)
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE03625AA 7750 SR 48-port GE copper/TX IOM (IMM) ✓ ✓ ✓
3HE04164AA 7750 SR-7 SF/CPM3 ✓
3HE04580AA 7750 SR-c12 CCM-XP ✓
3HE04741AA 7750 SR 5-port 10GE XFP IOM (IMM) ✓ ✓ ✓
3HE04743AAAB 7x50 12-port 10G Ethernet SFP+ IMM – L3HQ ✓ ✓
3HE05053AAAB 7x50 1-port 100G Ethernet CFP IMM – L3HQ ✓ ✓
3HE05055AA 7x50 1-port OC-768c/STM-256c OTU3 Long
✓ ✓ ✓
Reach DWDM Tunable IMM – L3HQ
3HE05553AA 7x50 12-port 10G Ethernet SFP+ IMM – L2HQ ✓ ✓
3HE05553BA 7x50 12-port 10G Ethernet SFP+ IMM – L3BQ ✓ ✓
3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long
✓ ✓ ✓
Reach DWDM Tunable IMM – L2HQ
3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long
✓ ✓ ✓
Reach DWDM Tunable IMM – L3BQ
3HE05814AA 7x50 1-port 100G Ethernet CFP IMM – L2HQ ✓ ✓
3HE05814BA 7x50 1-port 100G Ethernet CFP IMM – L3BQ ✓ ✓
3HE05895AA 7x50 48-port GE SFP IOM (IMM) – L2HQ ✓ ✓ ✓
3HE05895BA 7x50 48-port GE SFP IOM (IMM) – L3BQ ✓ ✓ ✓
3HE05896AA 7x50 48-port GE copper/TX IOM (IMM) –
✓ ✓ ✓
L2HQ
3HE05896BA 7x50 48-port GE copper/TX IOM (IMM) –
✓ ✓ ✓
L3BQ
3HE05898AA 7x50 5-port 10GE XFP IOM (IMM) – L2HQ ✓ ✓ ✓
3HE05898BA 7x50 5-port 10GE XFP IOM (IMM) – L3BQ ✓ ✓ ✓
3HE05899AA 7x50 8-port 10GE XFP IOM (IMM) – L2HQ ✓ ✓
3HE05899BA 7x50 8-port 10GE XFP IOM (IMM) – L3BQ ✓ ✓
3HE05948AA 7750 SR-12 SF/CPM4 ✓
3HE05949AA 7750 SR-7 SF/CPM4 ✓
3HE06318AA 7750 Multicore-CPU IOM3-XP-B ✓ ✓ ✓
3HE06320AA 7x50 3-port 40GE QSFP IMM – L3HQ ✓ ✓
3HE06326AA 7x50 48-port GE Multicore-CPU SFP IMM –
✓ ✓ ✓
L3HQ
3HE06326BA 7x50 48-port GE Multicore-CPU SFP IMM –
✓ ✓ ✓
L3BQ
3HE06326CA 7x50 48-port GE Multicore-CPU SFP IMM –
✓ ✓ ✓
L2HQ

7750 SR (Continued)
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE06428AA 7x50 48-port GE SFP IOM (IMM) – L3HQ ✓ ✓ ✓
3HE06429AA 7x50 48-port GE copper/TX IOM (IMM) –
✓ ✓ ✓
L3HQ
3HE06430AA 7x50 5-port 10GE XFP IOM (IMM) – L3HQ ✓ ✓ ✓
3HE06721BA 7x50 3-port 40GE QSFP IMM – L3BQ ✓ ✓
3HE06798AA 7750 1-port 40GE DWDM Tunable IMM –
✓ ✓ ✓
L3HQ
3HE06798BA 7750 1-port 40GE DWDM Tunable IMM –
✓ ✓ ✓
L3BQ
3HE06798CA 7750 1-port 40GE DWDM Tunable IMM –
✓ ✓ ✓
L2HQ
3HE07158AA 7x50 12-port 10GE FP3 SFP+ IMM – L3HQ ✓ ✓ ✓
3HE07158BA 7x50 12-port 10GE FP3 SFP+ IMM – L3BQ ✓ ✓ ✓
3HE07158CA 7x50 12-port 10GE FP3 SFP+ IMM – L2HQ ✓ ✓ ✓
3HE07159AA 7x50 1-port 100GE FP3 CFP IMM – L3HQ ✓ ✓ ✓
3HE07159BA 7x50 1-port 100GE FP3 CFP IMM – L3BQ ✓ ✓ ✓
3HE07159CA 7x50 1-port 100GE FP3 CFP IMM – L2HQ ✓ ✓ ✓
3HE07166AA 7750 SR-12e SF/CPM4-12e ✓
3HE07167AA 7750 SR-12e Mini-SFM4-12e ✓
3HE07303AA 7x50 2-port 100GE FP3 CFP IMM – L3HQ ✓ ✓ ✓
3HE07303BA 7x50 2-port 100GE FP3 CFP IMM – L3BQ ✓ ✓ ✓
3HE07303CA 7x50 2-port 100GE FP3 CFP IMM – L2HQ ✓ ✓ ✓
3HE07304AA 7x50 6-port 40GE FP3 QSFP IMM – L3HQ ✓ ✓ ✓
3HE07304BA 7x50 6-port 40GE FP3 QSFP IMM – L3BQ ✓ ✓ ✓
3HE07304CA 7x50 6-port 40GE FP3 QSFP IMM – L2HQ ✓ ✓ ✓
3HE07305AA 7x50 20-port 10GE FP3 SFP+ IMM – L3HQ ✓ ✓ ✓
3HE07305BA 7x50 20-port 10GE FP3 SFP+ IMM – L3BQ ✓ ✓ ✓
3HE07305CA 7x50 20-port 10GE FP3 SFP+ IMM – L2HQ ✓ ✓ ✓
3HE08019AA 7x50 1-port 100GE DWDM Tunable FP3 IMM
✓ ✓ ✓
– L3HQ
3HE08019BA 7x50 1-port 100GE DWDM Tunable FP3 IMM
✓ ✓ ✓
– L3BQ
3HE08019CA 7x50 1-port 100GE DWDM Tunable FP3 IMM
✓ ✓ ✓
– L2HQ

7750 SR (Continued)
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE08020AA 7x50 1-port 100GE CFP + 10-port 10GE SFP+
✓ ✓ ✓
FP3 IMM – L3HQ
3HE08020BA 7x50 1-port 100GE CFP + 10-port 10GE SFP+
✓ ✓ ✓
FP3 IMM – L3BQ
3HE08020CA 7x50 1-port 100GE CFP + 10-port 10GE SFP+
✓ ✓ ✓
FP3 IMM – L2HQ
3HE08173AA 7750 SR-c12 CFM-XP-B ✓
3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP
✓ ✓ ✓
FP3 IMM – L3HQ
3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP
✓ ✓ ✓
FP3 IMM – L3BQ
3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP
✓ ✓ ✓
FP3 IMM – L2HQ
3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3
✓ ✓ ✓
IMM – L3HQ
3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3
✓ ✓ ✓
IMM – L3BQ
3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3
✓ ✓ ✓
IMM – L2HQ
3HE08421AA 7750 SR SF/CPM5-12e ✓
3HE08422AA 7750 SR Mini-SFM5-12e ✓
3HE08423AA 7750 SR CPM5 ✓ ✓ ✓
3HE08424AA 7x50 40-port 10GE SFP+ IMM – L3HQ ✓
3HE08424BA 7x50 40-port 10GE SFP+ IMM – L3BQ ✓
3HE08424CA 7x50 40-port 10GE SFP+ IMM – L2HQ ✓
3HE08425AA 7x50 4-port 100GE CXP IMM – L3HQ ✓
3HE08425BA 7x50 4-port 100GE CXP IMM – L3BQ ✓
3HE08425CA 7x50 4-port 100GE CXP IMM – L2HQ ✓
3HE08426AA 7750 SR IOM3-XP-C ✓ ✓ ✓
3HE08428AA 7750 SR SFM5-12 ✓
3HE08429AA 7750 SR SFM5-7 ✓
3HE09117AA 7x50 Multiservice ISM ✓ ✓ ✓
3HE09118AA 7x50 Multiservice ISM-E (no encryption) ✓ ✓ ✓
3HE09192AA 7x50 MS-ISA2 + 1-port 100GE CFP IMM –
✓ ✓ ✓
L3HQ
3HE09192BA 7x50 MS-ISA2 + 1-port 100GE CFP IMM –
✓ ✓ ✓
L3BQ

7750 SR (Continued)
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE09192CA 7x50 MS-ISA2 + 1-port 100GE CFP IMM –
✓ ✓ ✓
L2HQ
3HE09193AA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM –
✓ ✓ ✓
L3HQ
3HE09193BA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM –
✓ ✓ ✓
L3BQ
3HE09193CA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM –
✓ ✓ ✓
L2HQ
3HE09201AA 7750 SR-a CPM ✓
3HE09202AA 7750 SR-a IOM – L3HQ ✓
3HE09202BA 7750 SR-a IOM – L3BQ ✓
3HE09202CA 7750 SR-a IOM – L2HQ ✓
3HE09253AA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM
✓ ✓ ✓
– L3HQ
3HE09253BA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM
✓ ✓ ✓
– L3BQ
3HE09253CA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM
✓ ✓ ✓
– L2HQ
3HE09254AA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM
✓ ✓ ✓
– L3HQ
3HE09254BA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM
✓ ✓ ✓
– L3BQ
3HE09254CA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM
✓ ✓ ✓
– L2HQ
3HE09260AA 7750 SR SFM5-12 + CPM5 ✓
3HE09261AA 7750 SR SFM5-7 + CPM5 ✓
3HE09279AA 7x50 48-port GE Multicore SFP IMM –
✓ ✓ ✓
L3HQ
3HE09279BA 7x50 48-port GE Multicore SFP IMM –
✓ ✓ ✓
L3BQ
3HE09279CA 7x50 48-port GE Multicore SFP IMM –
✓ ✓ ✓
L2HQ
3HE09645AA 7x50 4-Port 100GE CFP4 IMM – L3HQ ✓
3HE09645BA 7x50 4-Port 100GE CFP4 IMM – L3BQ ✓
3HE09645CA 7x50 4-Port 100GE CFP4 IMM – L2HQ ✓
3HE09648AA IOM – 7750 SR IOM4-e L3HQ 2 ✓ ✓ ✓
3HE09648BA IOM – 7750 SR IOM4-e L3BQ 2 ✓ ✓ ✓

7750 SR (Continued)
SR-1e/2e/3e
SR-a4/a8
SR-c12
SR-12e
SR-12
SR-7
Alcatel-Lucent
Part # Description
3HE09648CA IOM – 7750 SR IOM4-e L2HQ2 ✓ ✓ ✓
3HE10014AA IMM – 160-port GE cSFP/80-port GE SFP –
✓ ✓ ✓
L3HQ2
3HE10014BA IMM – 160-port GE cSFP/80-port GE SFP –
✓ ✓ ✓
L3BQ2
3HE10014CA IMM – 160-port GE cSFP/80-port GE SFP –
✓ ✓ ✓
L2HQ2
3HE10309AA CCM – 7750 SR-e CCM-e ✓
3HE10310AA CPM – 7750 SR-e CPM-e ✓
3HE10311AA IOM – 7750 SR IOM-e L3HQ ✓
3HE10311BA IOM – 7750 SR IOM-e L2HQ ✓
3HE10311CA IOM – 7750 SR IOM-e L3BQ ✓
1. The MCM is supported in the 7750 SR-c4.
2. Supported with SFM3/4/5.
Table 6. SFM, CPM, IOM, IMM, and ISM Cards Supported in 7450 ESS in Non-
Mixed Mode
ESS-6/6v
ESS-12
ESS-7
Alcatel-Lucent
Part # Description
3HE00229AA 7450 ESS 2 x 10G MDA IOM Card ✓ ✓ ✓
3HE00229AB 7450 ESS IOM 20G LINE CARD (iom-20g-b) ✓ ✓ ✓
3HE01172AA 7450 ESS SF/CPM2 200G ✓
3HE02032AA 7450 ESS SF/CPM2 400G ✓ ✓
3HE02297AA 7450 ESS SF/CPM2 80G ✓
3HE03618AA 7450 ESS-12 SF/CPM3 ✓ ✓
3HE03619AA 7750 SR IOM3-XP (iom3-xp) ✓ ✓ ✓
3HE03620AA 7450 ESS IOM3-XP (iom3-xp) ✓ ✓ ✓
3HE03624AA 7750 SR 48-port GE SFP IOM (IMM) ✓ ✓ ✓
3HE03625AA 7750 SR 48-port GE copper/TX IOM (IMM) ✓ ✓ ✓
3HE04166AA 7450 ESS-7 SF/CPM3 ✓
3HE04741AA 7750 SR 5-port 10GE SFP IOM (IMM) ✓ ✓ ✓

Mixed Mode (Continued)
ESS-6/6v
ESS-12
ESS-7
Alcatel-Lucent
Part # Description
3HE04743AAAB 7x50 12-port 10G Ethernet SFP+ IMM – L3HQ ✓ ✓
3HE05053AAAB 7x50 1-port 100G Ethernet CFP IMM- L3HQ ✓ ✓
3HE05055AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM
✓ ✓
Tunable IMM – L3HQ
3HE05553AA 7x50 12-port 10G Ethernet SFP+ IMM – L2HQ ✓ ✓
3HE05553BA 7x50 12-port 10G Ethernet SFP+ IMM – L3BQ ✓ ✓
3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM
✓ ✓
Tunable IMM – L2HQ
3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM
✓ ✓
Tunable IMM – L3BQ
3HE05814AA 7x50 1-port 100G Ethernet CFP IMM – L2HQ ✓ ✓
3HE05814BA 7x50 1-port 100G Ethernet CFP IMM – L3BQ ✓ ✓
3HE05895AA 7x50 48-port GE SFP IOM (IMM) – L2HQ ✓ ✓
3HE05895BA 7x50 48-port GE SFP IOM (IMM) – L3BQ ✓ ✓
3HE05896AA 7x50 48-port GE copper/TX IOM (IMM) – L2HQ ✓ ✓
3HE05896BA 7x50 48-port GE copper/TX IOM (IMM) – L3BQ ✓ ✓
3HE05950AA 7450 ESS-12 SF/CPM4 ✓
3HE05951AA 7450 ESS-7 SF/CPM4 ✓
3HE06320AA 7x50 3-port 40GE QSFP IMM- L3HQ ✓ ✓
3HE06326AA 7x50 48-port GE Multicore-CPU SFP IMM – L3HQ ✓ ✓ ✓
3HE06326BA 7x50 48-port GE Multicore-CPU SFP IMM – L3BQ ✓ ✓ ✓
3HE06326CA 7x50 48-port GE Multicore-CPU SFP IMM – L2HQ ✓ ✓ ✓
3HE06428AA 7x50 48-port GE SFP IOM (IMM) – L3HQ ✓ ✓
3HE06429AA 7x50 48-port GE copper/TX IOM (IMM) – L3HQ ✓ ✓
3HE06721BA 7x50 3-port 40GE QSFP IMM – L3BQ ✓ ✓
3HE06798AA 7750 1-port 40GE DWDM Tunable IMM – L3HQ ✓ ✓ ✓
3HE06798BA 7750 1-port 40GE DWDM Tunable IMM – L3BQ ✓ ✓ ✓

ESS-6/6v
ESS-12
ESS-7
Alcatel-Lucent
Part # Description
3HE06798CA 7750 1-port 40GE DWDM Tunable IMM – L2HQ ✓ ✓ ✓
3HE07158AA 7x50 12-port 10GE FP3 SFP+ IMM – L3HQ ✓ ✓
3HE07158BA 7x50 12-port 10GE FP3 SFP+ IMM – L3BQ ✓ ✓
3HE07158CA 7x50 12-port 10GE FP3 SFP+ IMM – L2HQ ✓ ✓
3HE07159AA 7x50 1-port 100GE FP3 CFP IMM – L3HQ ✓ ✓
3HE07159BA 7x50 1-port 100GE FP3 CFP IMM – L3BQ ✓ ✓
3HE07159CA 7x50 1-port 100GE FP3 CFP IMM – L2HQ ✓ ✓
3HE07303AA 7x50 2-port 100GE FP3 CFP IMM – L3HQ ✓ ✓
3HE07303BA 7x50 2-port 100GE FP3 CFP IMM – L3BQ ✓ ✓
3HE07303CA 7x50 2-port 100GE FP3 CFP IMM – L2HQ ✓ ✓
3HE07304AA 7x50 6-port 40GE FP3 QSFP IMM – L3HQ ✓ ✓
3HE07304BA 7x50 6-port 40GE FP3 QSFP IMM – L3BQ ✓ ✓
3HE07304CA 7x50 6-port 40GE FP3 QSFP IMM – L2HQ ✓ ✓
3HE07305AA 7x50 20-port 10GE FP3 SFP+ IMM – L3HQ ✓ ✓
3HE07305BA 7x50 20-port 10GE FP3 SFP+ IMM – L3BQ ✓ ✓
3HE07305CA 7x50 20-port 10GE FP3 SFP+ IMM – L2HQ ✓ ✓
3HE08019AA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L3HQ ✓ ✓
3HE08019BA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L3BQ ✓ ✓
3HE08019CA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L2HQ ✓ ✓
3HE08020AA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM –
✓ ✓
L3HQ
3HE08020BA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM –
✓ ✓
L3BQ
3HE08020CA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM –
✓ ✓
L2HQ
3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM –
✓ ✓
L3HQ
3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM –
✓ ✓
L3BQ
3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM –
✓ ✓
L2HQ
3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM –
✓ ✓
L3HQ
3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM –
✓ ✓
L3BQ
3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM –
✓ ✓
L2HQ

ESS-6/6v
ESS-12
ESS-7
Alcatel-Lucent
Part # Description
3HE08426AA 7750 SR IOM3-XP-C ✓ ✓ ✓
3HE08427AA 7450 ESS IOM3-XP-C ✓ ✓ ✓
3HE08430AA 7450 ESS SFM5-12 ✓
3HE08431AA 7450 ESS SFM5-7 ✓
3HE08432AA 7450 ESS CPM5 ✓ ✓
3HE09117AA 7x50 Multiservice ISM ✓ ✓
3HE09118AA 7x50 Multiservice ISM-E (no encryption) ✓ ✓
3HE09192AA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L3HQ ✓ ✓
3HE09192BA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L3BQ ✓ ✓
3HE09192CA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L2HQ ✓ ✓
3HE09193AA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L3HQ ✓ ✓
3HE09193BA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L3BQ ✓ ✓
3HE09193CA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L2HQ ✓ ✓
3HE09253AA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM – L3HQ ✓ ✓
3HE09253BA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM – L3BQ ✓ ✓
3HE09253CA 7x50 MS-ISA2-E + 1-port 100GE CFP IMM – L2HQ ✓ ✓
3HE09254AA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM – L3HQ ✓ ✓
3HE09254BA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM – L3BQ ✓ ✓
3HE09254CA 7x50 MS-ISA2-E + 10-port 10G SFP+ IMM – L2HQ ✓ ✓
3HE09262AA 7450 ESS SFM5-12 + CPM5 ✓
3HE09263AA 7450 ESS SFM5-7 + CPM5 ✓
3HE09279AA 7x50 48-port GE Multicore SFP IMM – L3HQ ✓ ✓ ✓
3HE09279BA 7x50 48-port GE Multicore SFP IMM – L3BQ ✓ ✓ ✓
3HE09279CA 7x50 48-port GE Multicore SFP IMM – L2HQ ✓ ✓ ✓
3HE09648AA IOM – 7750 SR IOM4-e L3HQ 1 ✓ ✓
3HE09648BA IOM – 7750 SR IOM4-e L3BQ1 ✓ ✓
3HE09648CA IOM – 7750 SR IOM4-e L2HQ1 ✓ ✓
3HE10014AA IMM – 160-port GE cSFP/80-port GE SFP – L3HQ 1 ✓ ✓
3HE10014BA IMM – 160-port GE cSFP/80-port GE SFP – L3BQ1 ✓ ✓
3HE10014CA IMM – 160-port GE cSFP/80-port GE SFP – L2HQ1 ✓ ✓
Table 7 summarizes the IOMs, IMMs, and ISMs supported in SR OS Release 13.0.R10 for the
7450 ESS in mixed mode.

Table 7. IOM, IMM, and ISM Cards Supported in the 7450 ESS in Mixed Mode
Alcatel-Lucent
Part # Description
3HE06318AA 7750 Multicore-CPU IOM3-XP-B
3HE03619AA 7750 SR IOM3-XP (iom3-xp)
3HE03622AA 7750 SR 4-port 10GE XFP IOM (IMM)
3HE03624AA 7750 SR 48-port GE SFP IOM (IMM)
3HE03625AA 7750 SR 48-port GE copper/TX IOM (IMM)
3HE04743AAAB 7750 SR 12-port 10G Ethernet SFP+ IMM
3HE05053AAAB 7750 SR 1-port 100G Ethernet CFP IMM
3HE05055AA 7750 SR 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable
IMM
3HE05553AA 7x50 12-port 10G Ethernet SFP+ IMM – L2HQ
3HE05553BA 7x50 12-port 10G Ethernet SFP+ IMM – L3BQ
3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM
– L2HQ
3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM
– L3BQ
3HE05814AA 7x50 1-port 100G Ethernet CFP IMM – L2HQ
3HE05814BA 7x50 1-port 100G Ethernet CFP IMM – L3BQ
3HE05895AA 7x50 48-port GE SFP IOM (IMM) – L2HQ
3HE05895BA 7x50 48-port GE SFP IOM (IMM) – L3BQ
3HE05896AA 7x50 48-port GE copper/TX IOM (IMM) – L2HQ
3HE05896BA 7x50 48-port GE copper/TX IOM (IMM) – L3BQ
3HE05898AA 7x50 5-port 10GE XFP IOM (IMM) – L2HQ
3HE05898BA 7x50 5-port 10GE XFP IOM (IMM) – L3BQ
3HE05899BA 7x50 8-port 10GE XFP IOM (IMM) – L3BQ
3HE06318AA 7750 Multicore-CPU IOM3-XP-B
3HE06320AA 7x50 3-port 40GE QSFP IMM- L3HQ
3HE06326AA 7x50 48-port GE Multicore-CPU SFP IMM – L3HQ
3HE06326BA 7x50 48-port GE Multicore-CPU SFP IMM – L3BQ
3HE06326CA 7x50 48-port GE Multicore-CPU SFP IMM – L2HQ
3HE06428AA 7x50 48-port GE SFP IOM (IMM) – L3HQ
3HE06429AA 7x50 48-port GE copper/TX IOM (IMM) – L3HQ

Alcatel-Lucent
Part # Description
3HE06721AA 7x50 3-port 40GE QSFP IMM – L2HQ
3HE06721BA 7x50 3-port 40GE QSFP IMM – L3BQ
3HE06798AA 7750 1-port 40GE DWDM Tunable IMM – L3HQ
3HE06798BA 7750 1-port 40GE DWDM Tunable IMM – L3BQ
3HE06798CA 7750 1-port 40GE DWDM Tunable IMM – L2HQ
3HE07158AA 7x50 12-port 10GE FP3 SFP+ IMM – L3HQ
3HE07158BA 7x50 12-port 10GE FP3 SFP+ IMM – L3BQ
3HE07158CA 7x50 12-port 10GE FP3 SFP+ IMM – L2HQ
3HE07159AA 7x50 1-port 100GE FP3 CFP IMM – L3HQ
3HE07159BA 7x50 1-port 100GE FP3 CFP IMM – L3BQ
3HE07159CA 7x50 1-port 100GE FP3 CFP IMM – L2HQ
3HE07303AA 7x50 2-port 100GE FP3 CFP IMM – L3HQ
3HE07303BA 7x50 2-port 100GE FP3 CFP IMM – L3BQ
3HE07303CA 7x50 2-port 100GE FP3 CFP IMM – L2HQ
3HE07304AA 7x50 6-port 40GE FP3 QSFP IMM – L3HQ
3HE07304BA 7x50 6-port 40GE FP3 QSFP IMM – L3BQ
3HE07304CA 7x50 6-port 40GE FP3 QSFP IMM – L2HQ
3HE07305AA 7x50 20-port 10GE FP3 SFP+ IMM – L3HQ
3HE07305BA 7x50 20-port 10GE FP3 SFP+ IMM – L3BQ
3HE07305CA 7x50 20-port 10GE FP3 SFP+ IMM – L2HQ
3HE08019AA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L3HQ
3HE08019BA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L3BQ
3HE08019CA 7x50 1-port 100GE DWDM Tunable FP3 IMM – L2HQ
3HE08020AA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM – L3HQ
3HE08020BA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM – L3BQ
3HE08020CA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM – L2HQ
3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM – L3HQ
3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM – L3BQ
3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM – L2HQ
3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM – L3HQ
3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM – L3BQ
3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM – L2HQ
3HE08426AA 7750 SR IOM3-XP-C
3HE09117AA 7x50 Multiservice ISM1
3HE09192AA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L3HQ1
3HE09192BA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L3BQ1

Alcatel-Lucent
Part # Description
3HE09192CA 7x50 MS-ISA2 + 1-port 100GE CFP IMM – L2HQ1
3HE09193AA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L3HQ1
3HE09193BA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L3BQ1
3HE09193CA 7x50 MS-ISA2 + 10-port 10GE SFP+ IMM – L2HQ1
3HE09279AA 7x50 48-port GE Multicore SFP IMM – L3HQ
3HE09279BA 7x50 48-port GE Multicore SFP IMM – L3BQ
3HE09279CA 7x50 48-port GE Multicore SFP IMM – L2HQ
3HE09648AA IOM – 7750 SR IOM4-e L3HQ2
3HE09648BA IOM – 7750 SR IOM4-e L3BQ2
3HE09648CA IOM – 7750 SR IOM4-e L2HQ2
3HE10014AA IMM – 160-port GE cSFP/80-port GE SFP – L3HQ2
3HE10014BA IMM – 160-port GE cSFP/80-port GE SFP – L3BQ2
3HE10014CA IMM – 160-port GE cSFP/80-port GE SFP – L2HQ2
1. MS-ISM and MS-ISA2 applications using MS-ISA2s are not supported in mixed mode with the
exception of Application Assurance, IPsec, and NAT. IPsec is not supported with MS-ISM-E
and MS-ISA2-E.
Supported Adapters (XMA, MDA, ISA, CMA, VSM)

The following tables summarize the XRS Media Adapters (XMAs), Media Dependent Adapters
(MDAs), Integrated Service Adapters (ISAs), Compact Media Adapters (CMAs), and Versatile
Services Modules (VSMs) supported in Release 13.0.R10.
Table 8. XMAs and C-XMAs Supported in 7950 XRS
Alcatel-Lucent
Part # Description
3HE06937AA C-XMA – 7950 XRS 20-port 10GE SFP+ – IP Core
3HE06938AA C-XMA – 7950 XRS 2-port 100GE CFP – IP Core
3HE06937BA C-XMA – 7950 XRS 20-port 10GE SFP+ – LSR
3HE06938BA C-XMA – 7950 XRS 2-port 100GE CFP – LSR
3HE07297AA XMA – 7950 XRS 40-port 10GE SFP+ – IP Core
3HE07297BA XMA – 7950 XRS 40-port 10GE SFP+ – LSR
3HE07299AA XMA – 7950 XRS 4-port 100GE CXP – IP Core
3HE07299BA XMA – 7950 XRS 4-port 100GE CXP – LSR

Table 8. XMAs and C-XMAs Supported in 7950 XRS (Continued)
Alcatel-Lucent
Part # Description
3HE08214AA C-XMA – 7950 XRS 6-port 40GE QSFP+ – IP Core
3HE08214BA C-XMA – 7950 XRS 6-port 40GE QSFP+ – LSR
3HE08631AA C-XMA – 7950 XRS 72-port GE CSFP – IP Core
3HE08631BA C-XMA – 7950 XRS 72-port GE CSFP – LSR
3HE08632AA XMA – 7950 XRS 4-port 100G CFP2 – IP Core
3HE08632BA XMA – 7950 XRS 4-port 100G CFP2 – LSR
Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR
SR-1e/2e/3e (iom-e)
SR-a4/a8 (iom-a)
iom3-xp/-b/-c
iom4-e and
iom-20g-b
SR-c4/c12
iom2-20g
Alcatel-Lucent
Part # Description
3HE00021AA 60-port 10/100TX MDA – mini-RJ21 ✓ ✓ ✓ ✓
3HE00023AA 20-port 100FX MDA – SFP ✓ ✓ ✓ ✓
3HE00025AA 5-port GigE MDA – SFP ✓ ✓
3HE00030AA 1-port 10GBASE-LW/LR MDA with optics – ✓ ✓ ✓
Simplex SC
3HE00031AA 1-port 10GBASE-EW/ER MDA with optics – ✓ ✓ ✓
Simplex SC
3HE00032AA 8-port OC-3c/STM-1c MDA – SFP ✓ ✓ ✓ ✓
3HE00033AA 16-port OC-3c/STM-1c MDA – SFP ✓ ✓ ✓
3HE00043AA 2-port OC-48c/STM-16c MDA – SFP ✓ ✓ ✓ ✓
3HE00048AA 1-port OC-192c/STM-64c MDA with SR-1/I- ✓ ✓ ✓
64.1 optic – Simplex SC
3HE00049AA 1-port OC-192c/STM-64c MDA with IR-2/S- ✓ ✓ ✓
3HE00071AA 4-port ATM OC-12c/STM-4c MDA – SFP ✓ ✓ ✓ ✓
3HE00074AA 16-port ATM OC-3c/STM-1c MDA – SFP ✓ ✓ ✓
3HE00101AB 20-port 10/100/1000TX MDA – RJ45 ✓ ✓ ✓
3HE00707AA 2-port 10GBASE MDA – XFP ✓ ✓ ✓

Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)
SR-1e/2e/3e (iom-e)
SR-a4/a8 (iom-a)
iom3-xp/-b/-c
iom4-e and
iom-20g-b
SR-c4/c12
iom2-20g
Alcatel-Lucent
Part # Description
3HE00708AA 20-port GigE MDA – SFP ✓ ✓ ✓
3HE00709AA 1-port OC-192c/STM-64c MDA with LR-2/L- ✓ ✓ ✓
3HE00710AA 1-port 10GBASE-ZW/ZR MDA with optics – ✓ ✓ ✓
Simplex SC
3HE00714AA 1-port 10GBASE MDA – XFP ✓ ✓ ✓
3HE01020AA 8-port Channelized DS1/E1 CMA – RJ48c ✓
3HE01021AA 4-port DS3/E3 CMA – 1.0/2.3 ✓
3HE01022AA 8-port 10/100TX Ethernet CMA – RJ45 ✓
3HE01023AA 1-port GigE CMA – SFP ✓
3HE01197AA 7750 SR Versatile Services Module (VSM) ✓ ✓ ✓
3HE01364AA 4-port Channelized OC-3/STM-1 (DS0) ASAP ✓ ✓ ✓
MDA – SFP
3HE01615AA 5-port GigE MDA – SFP Rev B ✓ ✓ ✓
3HE01616AA 10-port GigE MDA – SFP Rev B ✓ ✓ ✓
3HE02021AA 1-port 10GBASE + 10-port GIGE MDA ✓ ✓ ✓
3HE02185AA 2-port OC-3c/STM-1c/OC-12c/STM-4c CMA ✓
– SFP
3HE02499AA 1-port Channelized OC-12/STM-4 ASAP ✓ ✓ ✓
MDA
3HE02500AA 12-port Channelized DS3/E3 ASAP MDA ✓ ✓ ✓
3HE02501AA 4-port Channelized DS3/E3 ASAP MDA ✓ ✓ ✓
3HE03077AA 1-port Channelized OC-3/STM-1 CES CMA ✓
3HE03078AA 1-port Channelized OC-3/STM-1 CES MDA ✓ ✓
3HE03079AA 7750 SR 4-port CH OC3-1/STM-1 CES SFP ✓ ✓ ✓
MDA
3HE03609AA 1-port GE CMA-XP SFP ✓
3HE03610AA 5-port GE CMA-XP SFP ✓
3HE03611AA 7750 SR 10-port GE – XP – SFP MDA ✓ ✓ ✓ ✓
3HE03612AA 7750 SR 20-port GE – XP – SFP MDA ✓ ✓ ✓ ✓
3HE03613AA 7750 SR 20-port GE – XP – Copper/TX MDA ✓ ✓ ✓ ✓
3HE03685AA 7750 SR 2-port 10GBASE – XP – XFP MDA ✓ ✓ ✓ ✓
3HE03686AA 7750 SR 4-port 10GBASE – XP – XFP MDA ✓ ✓ ✓
3HE04179AA 7750 SR 10GBASE Tunable ZW/R MDA ✓ ✓ ✓

SR-1e/2e/3e (iom-e)
SR-a4/a8 (iom-a)
iom3-xp/-b/-c
iom4-e and
iom-20g-b
SR-c4/c12
iom2-20g
Alcatel-Lucent
Part # Description
3HE04272AA 7750 SR 1-port OC-12/STM-4 CES MDA ✓ ✓ ✓
3HE04274AA 7750 SR 1-port 10GBASE – XP – XFP MDA ✓ ✓ ✓ ✓
3HE04922AA 7750 SR / 7450 ESS Multiservice ISA1 ✓ ✓ ✓ ✓
3HE05142AA 7750 SR / 7450 ESS Multiservice ISA-E (no ✓ ✓ ✓ ✓
encryption)1
3HE05160AA 7750 SR 48-port 10/100/1000 – XP MDA – ✓
mini-RJ21
3HE05942AA 7750 SR / 7450 ESS Versatile Services Module ✓ ✓ ✓
XP (VSM-CCA-XP)
3HE05943AA 7750 SR 16-port OC-3/12c STM-1/4c POS ✓ ✓ ✓ ✓
MDA – SFP Rev B
3HE05944AA 7750 SR 16-port ATM OC-3c/STM-1c MDA – ✓ ✓ ✓
SFP Rev B
3HE05945AA 7750 SR 4-port ATM OC-12c/STM-4c MDA – ✓ ✓ ✓ ✓
SFP Rev B
3HE05946AA 7750 SR 4-port OC-48c/STM-16c POS MDA ✓ ✓ ✓ ✓
– SFP Rev B
3HE05947AA 7750 SR 2-port OC-192/STM-64 – XP – XFP ✓ ✓ ✓
MDA
3HE06432AA 7750 SR 10-port GE SFP HS-MDAv2 ✓
3HE06433AA 7750 SR 1-port 10GE HS-MDAv2 ✓
3HE06521AA 2-port OC-3c/STM-1c/OC-12c/STM-4c CMA ✓
– SFP Rev B
3HE07282AA 7750 SR 2-port 10GE XFP + 12-port GE SFP – ✓
XP MDA
3HE07284AA 7750 SR 12-port GigE – XP – SFP MDA ✓ ✓ ✓
3HE08220AA 8-port Channelized DS1/E1 CMA Rev B ✓
3HE09203AA 7750 SR-a 1-port 100GE MDA-a XP – CFP ✓
3HE09204AA 7750 SR-a 10-port 10GE MDA-a XP – SFP+ ✓
3HE09205AA 7750 SR-a 2-port 10GE SFP+ + 12-port GE ✓
SFP MDA-a
3HE09206AA 7750 SR-a 20-port 10/100/1000 TX MDA-a – ✓
RJ45
3HE09207AA 7750 SR-a 22-port GE SFP/44-port GE ✓
MDA-a – CSFP
3HE09240AA 7750 SR-a 4-port 10GE MDA-a – SFP+ ✓

SR-1e/2e/3e (iom-e)
SR-a4/a8 (iom-a)
iom3-xp/-b/-c
iom4-e and
iom-20g-b
SR-c4/c12
iom2-20g
Alcatel-Lucent
Part # Description
3HE09241AA 7750 SR-a 6-port 10GE SFP+ + 1-port 40GE ✓
QSFP+ MDA-a XP
3HE09649AA MDA-e 10-port 10 GE SFP+ ✓
3HE09881AA MDA-e 1-port 100 GE CFP2 ✓
3HE10421AA MDA–a XP - 7750 SR 1-PT 100G CFP2 ✓
3HE10422AA MDA–a XP - 7750 SR 1-PT 100G CFP4 ✓
3HE10427AA ISA - 7750 SR ISA2-MS1 ✓
3HE10428AA ISA - 7750 SR ISA2-MS-E1 ✓
3HE10429AA MDA-e 6-port 10GE SFP+ ✓
1. See Usage Notes for specifics.
Table 10. MDAs, ISAs, and VSMs Supported in 7450 ESS in Non-Mixed Mode
iom3-xp/-b/-c
iom-20g-b
iom4-e
Alcatel-Lucent
Part # Description
3HE00021AA 7750 SR 60-port 10/100TX MDA – mini-RJ211 ✓
3HE00023AA 7750 SR 20-port 100FX MDA – SFP1 ✓
3HE00030AA 7750 SR 1-port 10GBASE-LW/LR MDA with optics – Simplex ✓
SC1
3HE00031AA 7750 SR 1-port 10GBASE-EW/ER MDA with optics – Sim- ✓
plex SC1
3HE00033AA 7750 SR 16-port OC-3c/STM-1c MDA – SFP1 ✓
3HE00048AA 7750 SR 1-port OC-192c/STM-64c MDA with SR-1/I-64.1 ✓
optic – Simplex SC1

iom3-xp/-b/-c
iom-20g-b
iom4-e
Alcatel-Lucent
Part # Description
3HE00049AA 7750 SR 1-port OC-192c/STM-64c MDA with IR-2/S-64.2 ✓
3HE00101AB 7750 SR 20-port 10/100/1000TX MDA – RJ451 ✓
3HE00230AA 60-port 10/100TX MDA – mini-RJ21 ✓ ✓
3HE00231AA 20-port 100FX MDA – SFP ✓ ✓
3HE00232AA 10-port GigE MDA – SFP ✓
3HE00234AB 20-port 10/100/1000TX MDA – RJ45 ✓ ✓
3HE00235AA 1-port 10GBASE-LW/LR MDA with optics – Simplex SC ✓ ✓
3HE00236AA 1-port 10GBASE-EW/ER MDA with optics – Simplex SC ✓ ✓
3HE00237AA 16-port OC-3c/STM-1c MDA – SFP ✓ ✓
3HE00317AA 2-port 10GBASE MDA – XFP ✓ ✓
3HE00707AA 7750 SR 2-port 10GBASE MDA – XFP1 ✓
3HE00708AA 7750 SR 20-port GigE MDA – SFP1 ✓
3HE00709AA 7750 SR 1-port OC-192c/STM-64c MDA with LR-2/L-64.2 ✓
3HE00710AA 7750 SR 1-port 10GBASE-ZW/ZR MDA with optics – ✓
Simplex SC1
3HE00714AA 7750 SR 1-port 10GBASE MDA – XFP1 ✓
3HE01173AA 1-port 10GBASE-ZW/ZR MDA with optics – Simplex SC ✓ ✓
3HE01197AA 7750 SR Versatile Services Module (VSM)1 ✓
3HE01198AA 7450 ESS Versatile Services Module (VSM) ✓ ✓
3HE01532AA 10-port GigE MDA – SFP Rev B ✓ ✓
3HE01616AA 7750 SR 10-port GigE MDA – SFP Rev B1 ✓
3HE01617AA 1-port 10GBASE MDA – XFP ✓ ✓
3HE02021AA 7750 SR 1-port 10GBASE + 10-port GIGE MDA1 ✓
3HE02022AA 7450 ESS 1-port 10GBASE+10-port GigE MDA ✓ ✓
3HE03611AA 7750 SR 10-port GE – XP – SFP MDA1 ✓
3HE03612AA 7750 SR 20-port GE – XP – SFP MDA1 ✓

iom3-xp/-b/-c
iom-20g-b
iom4-e
Alcatel-Lucent
Part # Description
3HE03613AA 7750 SR 20-port GE – XP – Copper/TX MDA1 ✓
3HE03614AA 7450 ESS 10-port GE – XP – SFP MDA ✓ ✓
3HE03615AA 7450 ESS 20-port GE – XP – SFP MDA ✓ ✓
3HE03616AA 7450 ESS 20-port GE – XP – Copper/TX MDA ✓ ✓
3HE03685AA 7750 SR 2-port 10GBASE – XP – XFP MDA 1 ✓
3HE03686AA 7750 SR 4-port 10GBASE – XP – XFP MDA1 ✓
3HE03687AA 7450 ESS 2-port 10GBASE – XP – XFP MDA ✓ ✓
3HE03688AA 7450 ESS 4-port 10GBASE – XP – XFP MDA ✓ ✓
3HE04179AA 7750 SR 10GBASE Tunable ZW/R MDA 1 ✓
3HE04181AA 7450 ESS 10GBASE Tunable ZW/R MDA ✓ ✓
3HE04273AA 7450 1-port 10GBASE – XP – XFP MDA ✓ ✓
3HE04274AA 7750 SR 1-port 10GBASE – XP – XFP MDA 1 ✓
3HE04922AA 7750 SR / 7450 ESS Multiservice ISA2 ✓ ✓
3HE05142AA 7750 SR / 7450 ESS Multiservice ISA-E (no encryption)2 ✓ ✓
3HE05159AA 7450 SR 48-port 10/100/1000 – XP MDA – mini-RJ21 ✓
3HE05160AA 7750 SR 48-port 10/100/1000 – XP MDA – mini-RJ211 ✓
3HE05942AA 7750 SR / 7450 ESS Versatile Services Module XP (VSM- ✓ ✓
CCA-XP)
3HE05943AA 7750 SR 16-port OC-3/12c STM-1/4c POS MDA – SFP Rev B1 ✓
3HE05946AA 7750 SR 4-port OC-48c/STM-16c POS MDA – SFP Rev B1 ✓
3HE06382AA 7450 ESS 16-port OC-3/12c STM-1/4c POS MDA – SFP Rev ✓ ✓
B
3HE06383AA 7450 ESS 4-port OC-48c/STM-16c POS MDA – SFP Rev B ✓ ✓
3HE06432AA 7750 SR 10-port GE SFP HS-MDAv21 ✓
3HE06434AA 7450 ESS 10-port GE SFP HS-MDAv2 ✓
3HE06435AA 7450 ESS 1-port 10GE HS-MDAv2 ✓
3HE07282AA 7750 SR 2-port 10GE XFP + 12-port GE SFP –XP MDA1 ✓
3HE07283AA 7450 ESS 2-port 10GE XFP + 12-port GE SFP –XP MDA ✓
3HE07284AA 7750 SR 12-port GigE – XP – SFP MDA1 ✓
3HE07285AA 7450 ESS 12-port GigE – XP – SFP MDA ✓ ✓
3HE09649AA MDA-e 10-port 10 GE SFP+ ✓
3HE09881AA MDA-e 1-port 100 GE CFP2 ✓
3HE10427AA ISA – 7750 SR ISA2-MS ✓

iom3-xp/-b/-c
iom-20g-b
iom4-e
Alcatel-Lucent
Part # Description
3HE10428AA ISA – 7750 SR ISA2-MS-E ✓
3HE10429AA MDA-e 6-port 10GE SFP+ ✓
1. Supported only with 7750 SR IOM3-XP in the 7450 ESS chassis.
2. See Usage Notes for specifics.
The following table summarizes the MDAs, ISAs, and VSMs supported in SR OS Release
13.0.R10 for the 7450 ESS in mixed mode. 7750 SR MDAs must be configured in the 7750 SR
IOM3-XP or 7750 SR IOM4-e for mixed mode functionality. .
Table 11. MDAs, ISAs, and VSMs Supported in the 7450 ESS in Mixed Mode
Alcatel-Lucent
Part # Description
3HE00021AA 60-port 10/100TX MDA – mini-RJ21
3HE00023AA 20-port 100FX MDA – SFP
3HE00030AA 1-port 10GBASE-LW/LR MDA with optics – Simplex SC
3HE00031AA 1-port 10GBASE-EW/ER MDA with optics – Simplex SC
3HE00032AA 8-port OC-3c/STM-1c MDA – SFP
3HE00048AA 1-port OC-192c/STM-64c MDA with SR-1/I-64.1 optic – Simplex SC
3HE00049AA 1-port OC-192c/STM-64c MDA with IR-2/S-64.2 optic – Simplex SC
3HE00071AA 4-port ATM OC-12c/STM-4c MDA – SFP
3HE00101AB 20-port 10/100/1000TX MDA – RJ45
3HE00707AA 2-port 10GBASE MDA – XFP
3HE00708AA 20-port GigE MDA – SFP
3HE00709AA 1-port OC-192c/STM-64c MDA with LR-2/L-64.2 optic – Simplex SC
3HE00710AA 1-port 10GBASE-ZW/ZR MDA with optics – Simplex SC
3HE00714AA 1-port 10GBASE MDA – XFP
3HE01197AA 7750 SR Versatile Services Module (VSM)
3HE01364AA 4-port Channelized OC-3/STM-1 (DS0) ASAP MDA – SFP
3HE01616AA 10-port GigE MDA – SFP Rev B

Table 11. MDAs, ISAs, and VSMs Supported in the 7450 ESS in Mixed Mode
Alcatel-Lucent
Part # Description
3HE02021AA 1-port 10GBASE + 10-port GIGE MDA
3HE02499AA 1-port Channelized OC-12/STM-4 ASAP MDA
3HE02500AA 12-port Channelized DS3/E3 ASAP MDA
3HE02501AA 4-port Channelized DS3/E3 ASAP MDA
3HE03078AA 1-port Channelized OC-3/STM-1 CES MDA
3HE03079AA 7750 SR 4-port CH OC3-1/STM-1 CES SFP MDA
3HE03611AA 7750 SR 10-port GE – XP – SFP MDA
3HE03612AA 7750 SR 20-port GE – XP – SFP MDA
3HE03613AA 7750 SR 20-port GE – XP – Copper/TX MDA
3HE03685AA 7750 SR 2-port 10GBASE – XP – XFP MDA
3HE04179AA 7750 SR 10GBASE Tunable ZW/R MDA
3HE04272AA 7750 SR 1-port OC-12/STM-4 CES MDA
3HE04922AA 7750 SR / 7450 ESS Multiservice ISA1,2
3HE05142AA 7750 SR 7450 ESS Multiservice ISA-E (no encryption)1
3HE05160AA 7750 SR 48-port 10/100/1000 – XP MDA – mini-RJ21
3HE05942AA 7750 SR / 7450 ESS Versatile Services Module XP (VSM-CCA-XP)
3HE05943AA 7750 SR 16-port OC-3/12c STM-1/4c POS MDA – SFP Rev B
3HE05944AA 7750 SR 16-port ATM OC-3c/STM-1c MDA-SFP Rev B
3HE05945AA 7750 SR 4-port ATM OC-12c/STM-4c MDA – SFP Rev B
3HE05946AA 7750 SR 4-port OC-48c/STM-16c POS MDA – SFP Rev B
3HE05947AA 7750 SR 2-port OC-192/STM-64 –XP –XFP MDA
3HE06432AA 7750 SR 10-port GE SFP HS-MDAv2
3HE06433AA 7750 SR 1-port 10GE HS-MDAv2
3HE07282AA 7750 SR 2-port 10GE XFP + 12-port GE SFP –XP MDA
3HE07284AA 7750 SR 12-port GigE – XP – SFP MDA
3HE09649AA MDA-e 10-port 10GE SFP+
3HE09881AA MDA-e 1-port 100GE CFP2
3HE10427AA ISA – 7750 SR ISA2-MS
3HE10428AA ISA – 7750 SR ISA2-MS-E
3HE10429AA MDA-e 6-port 10GE SFP+
1. MS-ISAs and ISA applications using MS-ISAs are not supported in mixed mode with the
exception of Application Assurance, IPsec, NAT and FCC/RET. IPsec is not supported with
MS-ISA-E.
2. Starting with Release 8.0.R5, MS-ISA cards (3HE04922AA) replace IPsec-ISA cards
(3HE03080AA).


New Features
New Features
The following sections describe the new features added in SR OS releases.
Release 13.0.R10
Release 13.0.R10 has no new major features. See also Enhancements in Release 13.0.R10 and
Resolved Issues in Release 13.0.R10.
Features Added in • The following table summarizes the features that were added in releases prior to Release
Prior Releases 13.0.R10, but which were not documented in the SR OS Release Notes until Release
13.0.R10. Refer to the New Features section of the applicable release for details.
Table 15. Features Added Earlier than Release 13.0.R10
Component New Feature Release

HW/Platform MS-ISA2/MS-ISA2-E on SR-1e/2e/3e 13.0.R9
Release 13.0.R9
HW/Platform
MS-ISA2/ In Release 13.0.R9, the Multi-Service Integrated Service Adapter (MS-ISA2), introduced in
MS-ISA2-E on Release 13.0.R7 for IOM4-e, is now also supported on 7750 SR-1e/2e/3e platforms.
SR-1e/2e/3e
7750 SR-1e/2e/3e Release 13.0.R9 introduces the 7750 SR-e family of routers; the Alcatel-Lucent 7750 SR-e
platform series enables the delivery of advanced residential, business and mobile services. The
7750 SR-e series provides high-performance networking for cloud, data center and branch
office applications.
As a member of the Alcatel-Lucent 7750 SR product portfolio, the 7750 SR-e platform employs
the 7750 SR hardware architecture and the SR OS. The 7750 SR-e is FP3-based, which is
programmable to allow the 7750 SR-e to adapt to new features and protocols.
The 7750 SR-e platform supports a wide range of SR OS features, including a variety of services
and protocols, OAM capabilities, and QoS features, all of which are managed by the
Alcatel-Lucent 5620 Service Aware Manager (SAM).
The 7750 SR-e is available in three hardware configurations:

New Features
• 7750 SR-1e chassis, which supports:

− a total system capacity of 200 Gb/s (full duplex), 6RU
− up to two (2) CPM-e (1+1 redundancy) cards, one (1) IOM-e card and four (4)
MDA-e cards
− up to four (4) AC or DC Power-Supply Units (PSUs) (universal AC and –48 VDC are
available)
− up to two (2) CPM-e (1+1 redundancy) cards, two (2) IOM-e cards and eight (8)
MDA-e cards
− up to four (4) AC or DC PSUs (universal AC and –48 VDC are available)
− up to two (2) CPM-e (1+1 redundancy) cards, three (3) IOM-e cards and twelve (12)
MDA-e cards
− up to four (4) AC or DC PSUs (universal AC and –48 VDC are available)
All three configurations have full system redundancy with common components that are
modular and hot-swappable to provide increased system uptime and future upgradeability.
CPM-e, CCM-e, IOM-e, MDA-e cards, and PSUs are designed for use in all three 7750 SR-e
chassis. MDA-e cards are also compatible with 7750 SR and 7450 ESS IOM4-e.
Control The 7750 SR-e CPM-e provides intelligent control and processing functionality. The CPM-e
Processing offers optional 1+1 redundancy and is hot-swappable. Redundant CPM-e’s operate in a hitless,
Module (CPM-e) stateful, failover mode.
Chassis Control The 7750 SR-e CCM-e provides an interface to the CPM-e and is hot-swappable. The CCM-e
Module (CCM-e) provides one-to-one relationship with its associated CPM-e. For timing and synchronization,
each CCM-e has an RJ45 BITS port and a 1PPS port. The CCM-e supports a 10/100BASE
(RJ45) management interface, RJ45 serial console port (DCE/DTE switch) and an RJ45 OES
port.
Input/Output The 7750 SR-e IOM-e provides up to 200 Gb/s (full duplex) connectivity to MDA-e and
Module (IOM-e) MS-ISA2(-E) modules. Optimized for versatility in Ethernet and IP-based services and
applications, each IOM-e uses a multicore CPU and supports up to four (4) MDA-e and MS-
ISA2(-E) modules. Based on FP3, the IOM-e provides the forwarding and service functions
along with high-end traffic management capabilities.
Media Dependent The MDA-e, usable in both IOM4-e for 7750 SR and 7450 ESS, and 7750 SR-e IOM-e,
Adapter (MDA-e) supports up to 100 Gb/s (full duplex) and provide physical Ethernet interface connectivity. They
are available in a variety of Ethernet-speed and port-density configurations.

New Features
Release 13.0.R8
HW/Platform
IEEE 1588 IEEE 1588 port-based timestamping capability has been added to the 1G ports (p20-1gb-sfp) of
Port-Based the assemblies in Table 12. To unlock this capability on the ports of these IMMs, the firmware
Timestamping must be upgraded. If SR OS has been upgraded via ISSU, then the firmware may not have been
upgraded automatically. In these cases, the operator must perform a hard reset of the IMM using
the clear card command to upgrade the firmware.
The firmware version can be checked in the detailed show information of the assembly (for
example, show mda 1/1 detail).
Table 12. Additional Hardware Assemblies with 1G Port IEEE 1588 Port-Based
Timestamping Capability
Alcatel-Lucent Part # Description
3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3HQ
3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3BQ
3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L2HQ
3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3HQ
3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3BQ
3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L2HQ
Release 13.0.R7
HW/Platform
7950 XRS-40 30m Release 13.0.R7 introduces the 30-meter-long interconnect cable support for the 7950 XRS-40
chassis inter- system.
connect cable
support
System Alarm Release 13.0.R7 adds the software support for the input alarm pins on the Alarms Interface Port
Contact Inputs for of the CPM on the 7750 SR-a platform. The alarm inputs allow the operator to monitor and
7750 SR-a report changes in the external environmental conditions. In a remote or outdoor deployment,
alarm inputs typically allow an operator to detect door open/close, air conditioner fault, etc.
There are four (4) separate input pins, each of which can be configured with an associated
severity and normally-open/normally-closed state. There is also a single output power pin that
can be used to supply power for the alarm inputs. When an input pin changes state, the router
can generate log events and raise facility alarms.

New Features
1-port 100G CFP2 Release 13.0.R7 introduces two new MDA-a XP cards utilized within the 7750 SR-a4/a8
MDA-a XP and platforms:
1-port 100G CFP4 • 1-port 100G CFP2
MDA-a XP
• 1-port 100G CFP4
These cards support Alcatel-Lucent-sourced 100GBase CFP2 and CFP4 optic modules (not
included).
MS-ISA2/ Release 13.0.R7 introduces the Multi-Service Integrated Service Adapter (MS-ISA2) for the
MS-ISA2-E 7750 SR IOM4-e (also supported on 7450 ESS). MS-ISA2-E has been created for exporting to
encryption-restricted countries.
The MS-ISA2-E application support is the same as the MS-ISA2 except for IPsec and IP
Tunnels, similar to the MS-ISM and MS-ISA2 IMMs, the export restricted variants (-E).
To run any of these applications, the hardware and appropriate software RTU licenses must be
purchased.
Release 13.0.R6
HW/Platform
APEQ-DC-2200- In Release 13.0.R6, a new DC 60A/80A software-configurable Advanced Power Equalizer

2800 Power (APEQ) module is supported on 7750 SR-12e and 7950 XRS systems.
Equalizer Module
APEQ-AC-3000 AC In Release 13.0.R6, AC power is supported on 7750 SR-12e and 7950 XRS systems using the
Power Equalizer new single phase AC APEQ module.
Module
6x10GE SFP+ Release 13.0.R6 introduces a new 6-port 10GE SFP+ MDA-e utilized on the IOM4-e. The
MDA-e for IOM4-e 6-port 10GE SFP+ MDA-e supports:
• FEC/G.709
• LAN/WAN, OTN framing OTU1e, OTU2, and OTU2e at line rate for use in a wide range
of optical transport networking (OTN) environments
• ITU-T Synchronous Ethernet (SyncE)

New Features
IEEE 1588 IEEE 1588 Port-Based Timestamping has been introduced on a new hardware assembly as
Port-Based shown below. For this assembly, no firmware upgrade is required to unlock this feature.
Timestamping on
Additional MDA Table 13. Additional Hardware with IEEE 1588 Port-Based Timestamping Capability

3HE10429AA 6-port 10GE SFP+ MDA-e
Dual frequency The 7750 SR-a4 permits the assignment of two line reference inputs to the central clock to be
reference on from its single IOM. In normal operating mode, this permits redundant frequency references to
7750 SR-a4 both CPMs.
Routing
Selective FIB Release 13.0.R6 introduces the support for IP FIB selective route install. When this feature is
enabled on an SR OS router, every line card in the chassis decides, for every downloaded IP
route, whether or not it should program the route into its forwarding table. A route is
programmed only if it is relevant to the line card based on the configuration of interfaces and
services. For example, with selective FIB enabled, an IP route belonging to VPRN service A is
not installed on a line card with only access interfaces belonging to VPRN service B. With
careful planning, the use of selective FIB allows the effective FIB capacity of the system to
exceed the FIB limit of the line card with the smallest capacity. Selective FIB requires the
system to have CPM3 or higher.
MPLS
Class-Based Release 13.0.R6 extends the scope of applicability of Class-Based Forwarding. LDP prefixes
Forwarding that are resolved to a set of ECMP tunnel next-hops (IGP shortcuts) can now have forwarding-
class specified packets sent to LSPs configured with the matching forwarding class.
Services
PBF: Nuage Release 13.0.R6 introduces the support for integrated Nuage and SR OS router service chaining
Service Chaining solution for VPLS using IPv4/MAC ESI PBF for EVPN on all SR OS FlexPath-based
for VPLS using platforms. To achieve the steering:
IPv4/MAC Filter • An operator must configure a PBF match/action filter policy entry in an IPv4 or MAC
ESI PBF for EVPN ingress access or network filter deployed on a VPLS interface. The PBF target identifies
the first service function in the chain (Ethernet Segment Identifier (ESI) which defines
where the appliance is connected) and the VPLS service for the egress EVPN VXLAN
interface.

New Features
• An operator must configure a BGP peering session between the router and the data center
controller. The session is used to convey to the router the MP-BGP EVPN route required to
reach the service chain (Ethernet Auto-Discovery (A-D) route for the specified ESI
identifier). The BGP control plane together with the ESI PBR configuration are used to
forward the matching packets to the next-hop in the EVPN-VXLAN data center chain
(through resolution to a VXLAN Network Identifier and VXLAN Termination Endpoint).
If the BGP control plane information is not available, the packets matching the ESI PBF
entry will be, by default, forwarded using regular forwarding. Optionally, an operator can
select to drop the packets when the ESI PBF target is not reachable. See Known
Limitations for more information.
Subscriber
Management
NAT: Active-Active The “active-active” MS-ISA/MS-ISA2 redundancy model is now supported for Layer 2-Aware
MS-ISA/ NAT, previously only supported for NAT on DS-Lite, LSN and NAT64. When all ISAs are
MS-ISA2 active and up to two ISAs fail, traffic will then be distributed over the remaining active ISAs.
Redundancy [210472]
Model
Release 13.0.R5
Hardware
IMM - 160-port GE Release 13.0.R5 introduces the 160-port GE cSFP/80-port GE SFP MultiCore-CPU-based
cSFP/80-port GE IMMs to the Alcatel-Lucent IMM family. These IMMs are based on the FP3 chipset. Providing
SFP 160G of bandwidth, these IMMs:
• are supported in the 7750 SR-7/12 and 7450 ESS-7/12 with SFM3/4/5 and above, and in
the 7750 SR-12e with SFM4/5 and above
• provide 128K queues flexibly configurable to any/all ports for ingress and/or egress
• can co-exist and are interoperable with all released IOMs/IMM/ISMs (must use a chassis
mode that aligns with the earliest generation of IOMs installed in the chassis)
• support chassis mode D when a chassis is configured entirely with any combination of
IOM3-XP/IMM/ISMs
• support 200 GB for full line rate on the 7750 SR-12e with SFM4 and SFM5 and on the
7750 SR-7/12 with SFM5 and the switch fabric speed set to fabric-speed-b
• support Alcatel-Lucent-sourced GE cSFP/SFP optic modules (not included)
• require an upgrade to PEM-3 and to the latest Enhanced Fan Tray for power and cooling
requirements
• support Soft Reset

New Features
There are Right-to-Use (RTU) licenses associated with IMM hardware depending on the
features used. Contact your Alcatel-Lucent representative for the appropriate application
licenses.
IMPORTANT NOTE: Impedance panels must be purchased and installed in all systems in
which an IMM is used. These impedance panels provide highly efficient air flow in support of
the higher performing IOM3 and newer IOM/IMM/ISM modules. Note that even when only one
IMM/IOM/ISM is deployed, impedance panels are required.
IEEE 1588 Support The 7750 SR-a4/a8 platforms now support IEEE 1588 for distribution of frequency and time.
on 7750 SR-a4/a8 The support includes all of the features available on other platforms supporting IEEE 1588
including
• Ordinary-Master, Ordinary-Slave, and Boundary clocks
• default, G.8265.1, and G.8275.1 profiles
• Unicast IPv4 and Multicast Ethernet transport
Port-Based IEEE 1588 Port-Based Timestamping has been introduced on hardware assemblies of the 7750
Timestamping on SR-a4/a8 as shown below. The support is available on the 1GE and 10GE ports only and is not
7750 SR-a4/a8 available on 40GE or on Electrical Ethernet ports in 10 Mbps mode.
MDAs
Table 14. 7750 SR-a4/a8 with IEEE 1588 Port-Based Timestamping Capability
3HE09201AA 7750 SR-a CPM
3HE09202AA 7750 SR-a IOM - L3HQ
3HE09202BA 7750 SR-a IOM - L3BQ
3HE09202CA 7750 SR-a IOM - L2HQ
3HE09204AA 7750 SR-a 10-port 10GE SFP+ MDA-a XP
3HE09205AA 7750 SR-a 2-port 10GE SFP+ + 12-port GE SFP MDA-a
3HE09206AA 7750 SR-a 20-port 10/100/1000 TX MDA-a
3HE09207AA 7750 SR-a 44-port GE cSFP/22-port GE SFP MDA-a
3HE09240AA 7750 SR-a 4-port 10GE SFP+ MDA-a
3HE09241AA 7750 SR-a 6-port 10GE SFP+ + 1-port 40GE QSFP+ MDA-a
XP
1588 Port-Based IEEE 1588 Port-Based Timestamping has been introduced on a new hardware assembly as
Timestamping on shown below. For this assembly, no firmware upgrade is required to unlock this feature.
Additional MDA
Table 15. Additional Hardware with IEEE 1588 Port-Based Timestamping Capability

3HE09649AA MDA-e 10-port 10 GE SFP+

New Features
System
In-service ISSU (in-service software update) across minor releases (Minor ISSU) allows in-service
Software Update software updates across maintenance releases (within the same major release) for systems with
(ISSU) Across dual CPMs or CFMs without requiring a reboot of the system. ISSU is comparable to
Minor Releases performing a controlled High-Availability switchover where the new image is loaded onto the
standby CPM or CFM which becomes master, and then upgrading the image on the other CPM
or CFM. Minor ISSU does not apply to 7750 SR-c4. The terms Major ISSU and Minor ISSU
are used to differentiate between ISSU across major releases and maintenance releases within a
major release respectively.
Routing
General Support In Release 13.0.R5, the BGP implementation in SR OS introduces broad support for dynamic
for Dynamic BGP BGP sessions. Previously, dynamic sessions were only supported for ESM subscribers. When
Sessions BGP in the base router or a VPRN is configured to support dynamic sessions, it accepts
incoming BGP connection attempts from source IP addresses that matches specified prefixes;
BGP connection establishment no longer requires a source IP to match a statically-configured
neighbor address. The parameters that apply to a dynamic session are inherited from the BGP
group with the longest matching prefix for the source IP address. The implementation allows
configurable limits on the maximum number of established dynamic sessions per instance
and/or per group. See Enhancements in Release 13.0.R6 for more information.
Subscriber
Management
ESM BGP Prior to Release 13.0.R5, dynamic BGP peering was only supported for ESM hosts. Release
13.0.R5 adds dynamic BGP peering support for non-ESM hosts. To avoid any confusion
between the two, ESM-based dynamic BGP peering has been changed to esm-dynamic-
peering, and consequently, the dynamic-peering parameter has been deprecated. See Changed
or Deprecated Commands for more information.
Release 13.0.R4
The following sections describe the new features added in Release 13.0.R4 of SR OS.
− Hardware
− System
− Quality of Service
− Routing
− MPLS

New Features
− Services
− Subscriber Management
− Application Assurance
− OAM
Hardware
7750 SR-7/12 and Release 13.0.R4 introduces 200 Gb/s per slot support in the 7750 SR-7/12 and the 7450 ESS-
7450 ESS-7/12 7/12 with SFM5. To achieve this level of throughput, the chassis will require all T3-based
200 Gb/s per Slot IOMs/IMMs. A new tools command is introduced to set the switch fabric speed to fabric-
with SFM5 speed-b which will enable 200 Gb/s per slot after rebooting the system. If Major ISSU is used
to upgrade to Release 13.0.R4 or later, then the system will not automatically change to the
faster fabric speed (the tools command and reboot will be necessary after the ISSU for the faster
performance to be in effect).
IOM4-e Release 13.0.R4 introduces the new IOM4-e (Input/Output Module) for the 7450 ESS-7/12 and
7750 SR-7/12/12e platforms. Each IOM4-e MultiCore-CPU line card accepts up to two (2)
MDA-e cards.
The IOM4-e uses the FP3 chipset, providing the following key benefits:
• supports up to 200 Gb/s (full duplex) in the 7750 SR-7/12 and 7450 ESS-7/12 with SFM5
and in the 7750 SR-12e with SFM4 and SFM5. To achieve this level of throughput on the
7750 SR-7/12 and 7450 ESS-7/12 platforms, the chassis will require all T3-based
IOMs/IMMs and the switch fabric speed set to fabric-speed-b.
• supports 100 Gb/s throughput with SF/CPM4 on the 7750 SR-7/12 and 7450 ESS-7/12
platforms.
• maximum of 128k queues in total for ingress and egress directions, which can be flexibly
assigned to any port
• full range of edge services with deterministic performance
• Soft Reset support
There are Right-to-Use (RTU) licenses associated with IOM4-e hardware depending on the
licenses.
which a line card is used. These impedance panels provide highly efficient air flow in support
of the higher performing IOM3-XP/-B/-C, IOM4-e and newer IMM/ISM modules. Note that
even when only one IMM/IOM/ISM is deployed, impedance panels are required. See Limited
Support Features and Enhancements for more information.
10-port 10GE SFP+ Release 13.0.R4 introduces a new family of MDA-e cards utilized on the IOM4-e. There are
MDA-e and 1-port two variants of MDA-e, both supporting FEC/G.709:
100GE CFP2 • 10-port 10GE SFP+
MDA-e

New Features
− supports LAN/WAN, OTN framing OTU1e, OTU2, and OTU2e at line rate for use in
a wide range of optical transport networking (OTN) environments
− supports ITU-T Synchronous Ethernet (SyncE)
• 1-port 100GE CFP2
− supports 100GE Ethernet and OTN OTU4 framing
System
Enhanced CLI Authorization based on locally-configured profiles has been enhanced to allow more granular
Authorization access control to CLI branches and objects. Release 13.0.R4 supports the matching of
parameters and optional parameters in CLI commands, allowing an operator to permit or deny
different users from accessing objects such as service or policy instances (for example, system
interface in comparison to all other interfaces, or VPRN 5 in comparison to VPRN 6).
SR OS also now allows the operator to give users read-only access to sub-branches of the router
configuration.
Note that some special characters are not usable in the match criteria. Notably, they are:
• characters “<”, “>”
• double quotes “” inside the match string. For example: match “configure router interface
“if name with space”” will not correctly match if an operator tries to enter the context for
that particular interface.
Hierarchical CLI The concept of CLI session management has been introduced to control or limit the number of
Session Limits CLI sessions opened by one user. The sessions are limited using a two-level hierarchy via
profiles and a new concept called a cli-session-group. CLI session groups can be used to create
different Telnet or SSH session limits for different groups of users. Log events indicate when
the user is attempting to exceed the limit.
IEEE 1588 IEEE 1588 Port-Based Timestamping has been introduced on new hardware assemblies as
Port-Based shown below. To unlock this capability on ports of these MDAs, the firmware must be
Timestamping on upgraded. If SR OS has been upgraded via ISSU, then the firmware may not have been
Additional MDAs upgraded automatically. In these cases, the operator must hard reset the IMM or MDA using the
clear card or clear mda commands to upgrade the firmware.
Note: The firmware version can be checked in the detailed show information of the assembly
(for example, show mda 1/1 detail).
Table 16. Additional Hardware with IEEE 1588 Port-Based Timestamping Capability

3HE07282AA 7750 SR 2-port 10GE XFP + 12-port GE SFP -XP MDA
3HE07283AA 7450 ESS 2-port 10GE XFP + 12-port GE SFP-XP MDA
3HE07284AA 7750 SR 12-port GigE - XP - SFP MDA
3HE07285AA 7450 ESS 12-port GigE - XP - SFP MDA

New Features
IEEE 1588 Support The IEEE 1588 functionality has been enhanced with the addition of support for the ITU-T
for ITU-T G.8275.1 G.8275.1 profile. This profile specifies how to use IEEE 1588 to distribute a time reference to
meet the requirements of mobile base-stations.
Filter Policies: TTL Release 13.0.R4 introduces TTL match support in IPv4 ingress filter policies for the drop action.
Match Support in Greater-than, less-than, equal to, and range operators are supported with the TTL condition. A
IPv4 Filters packet matching an IPv4 ingress filter policy entry with a conditional TTL drop action
configured is discarded when the TTL value in the IPv4 header matches the condition
configured. If the TTL condition is not met, the packet is forwarded. When the filter entry with
conditional action is used as a mirror source, only packets matching the entry’s match criteria
and the TTL condition are mirrored. When the entry is used in Cflowd, packets are processed
for Cflowd based on the entry’s match criteria, whether or not the TTL action condition is met.
TTL condition is supported on FP2- and higher-based line cards on all platforms. Filter policies
with conditional TTL action are not supported in egress directions and on FP1 line cards.
Deploying a filter policy with TTL conditional action in those scenarios may lead to an
unexpected behavior (for example, packets matching an entry are always dropped) and thus
should be avoided.
Filter Release 13.0.R4 allows operators to configure sticky destination selection in IPv4 and IPv6
Policies/PBR: redirect policies (config>filter>redirect-policy>sticky-dest). Upon start-up, or when the first
Redirect policy redirect-policy destination becomes available, a delay timer is started (configurable). When the
Sticky Destination timer expires, a best destination from all available destinations is selected and programmed as
Selection an active, sticky destination.
The currently active, sticky destination remains active until one of the following occurs:
• the destination goes down
• an operator forces the switch manually (tools>perform>filter>redirect-policy>activate-
best-dest).
PBR: ESM Release 13.0.R4 introduces the support for egress PBR on Layer-3 (L3) IES/VPRN subscriber-
Downstream facing interfaces for subscriber-destined downstream traffic. An operator can control traffic
Traffic Steering steering per ESM subscribers/hosts with an IP flow-level granularity using IPv4 ACL filter
Using Egress IPv4 policies. Upstream traffic is steered using ingress subscriber/host-assigned IPv4 ACLs with
ACLs with PBR ingress PBR rules (existing functionality); downstream traffic is steered using egress
Action subscribers/host-assigned IPv4 ACLs with egress PBR rules (new in Release 13.0.R4). Because
steering is based on ACLs assigned to hosts/subscribers, operators no longer need to use other
techniques to identify subscriber traffic to be redirected to Value Added Services (VAS)—for
example, IP address pools or DSCP remark per ESM service type.
Any egress-supported ACL match condition is supported in egress PBR steering, allowing full
flexibility of selecting not only which subscribers or hosts have to be redirected but also what
flows for those subscribers or hosts are to be redirected. Supported egress PBR actions include:
• action forward esi sf-ip vas-interface router (Nuage integrated service-chaining support)
• action forward redirect-policy (IP-based service-chaining/steering including)
To ensure that downstream traffic is not steered again after VAS processing, the traffic must
return over a dedicated L3 interface configured to indicate post-VAS downstream traffic on
ingress (refer to the vas-if-type command in the user guides for more information).

New Features
The feature is supported with integrated Application Assurance (AA) for platforms that support
AA. If deployed with AA, both upstream and downstream traffic are subject to AA before
steering to VAS. Configuring egress-PBR as part of ACLs deployed in the context other than
ESM subscriber/host is not blocked but not recommended.
PBR: Nuage Release 13.0.R4 introduces the support for integrated Nuage and SR OS router service chaining
Service Chaining solution for IES/VPRN using IPv4 ESI PBR for EVPN on all SR OS FlexPath-based hardware
for IES/VPRN platforms. To achieve the steering, an operator must configure the following items:
using IPv4 Filter • a PBR match/action filter policy entry in an IPv4 ingress access or network filter deployed
ESI PBR for EVPN on an IES/VPRN interface. The PBR target identifies the first service function in the chain
(the Ethernet Segment Identifier (ESI), which identifies where the appliance is connected,
and the IPv4 address of the appliance) and the EVPN VXLAN egress interface on the PE
(the routing instance and interface name).
• the BGP peering session between the router and the data center controller—The session is
used to convey to the router MP-BGP EVPN routes (route type 1 and 2) required to reach
the service chain. The BGP control plane, together with the ESI PBR configuration, are
used to forward the matching packets to the next-hop in the EVPN-VXLAN data center
chain (through resolution to a VXLAN Network Identifier and VXLAN Termination
Endpoint). If the BGP control plane information is not available, the packets matching the
ESI PBR entry will be, by default, forwarded using regular routing. Optionally, an operator
can select to drop the packets when the ESI PBR target is not reachable using the pbr-
down-action-override command.
LAG • Release 13.0.R4 introduces the following enhancements to mixed-speed member port LAG
support:
− support for a mix of 10GE/40GE/100GE ports in a single LAG
− support for access and hybrid modes
− support for MC-LAG and LAG with multiple sub-groups
− support for service hash, per-link-hash, and LAG link map profiles
− support for MCAC, VRRP, ETH-CFM, micro-BFD
− support for configurable Tier-0 scheduler
See Enhancements in Release 13.0.R7 for more information about Mixed-Speed LAG with
ESM.
LAG/ECMP Hashing distribution has been optimized for link aggregation groups with more than 16 links
Hashing and for ECMP with more than 16 paths.
Optimization
TEID-based Release 12.0 introduced TEID-based hashing for IP interfaces. Release 13.0.R4 enhances this
Hashing for functionality by adding the support for GTP-U- and GTP-C-encapsulated traffic on Layer-2
Layer-2 VPLS VPLS services. This functionality allows a deployed SR OS router (for example, in an LTE
Interfaces mobile backhaul network) to use a TEID value from a GTP v1/v2 packet header in hash inputs
in addition to Layer-3/4 IP input for a better traffic distribution across multiple ECMP

New Features
paths/LAG links. TEID-based hashing can be enabled per service (VPLS). The hashing
configuration applies to traffic ingressing the system on an FP2- or higher-based line card and
egressing the system over LAG/ECMP.
Inner IP Release 13.0.R4 introduces the ability to use inner IPv4/v6 header inputs for hashing of IPv4
Header-based and IPv6 unicast and multicast traffic encapsulated in an IPv4 tunnel (such as GRE) for traffic
Hashing for IPv4 distribution over LAG links/ECMP. By enabling the inner IP header hash for IPv4 tunnels, the
Tunneled Traffic system replaces outer IP inputs (for example, GRE tunnel IP) with those of inner IP (user data)
in the hash. Inner IP-based IPv4 tunneled traffic hashing can be enabled per interface. The
hashing configuration will apply to traffic ingressing system on FP2- or higher-based line cards
and egressing the system over LAG/ECMP.
In-Service Major ISSU support has been added to the 7950 XRS-40 platform. The first Major ISSU path
Software Upgrade for a 7950 XRS-40 system is from Release 12.0.R6 to Release 13.0.R4.
(ISSU) Across
Major Releases for
7950 XRS-40
In-service Major ISSU (In-Service Software Update) allows in-service updates across a major release for
Software Update systems with dual-CPMs without requiring a reboot of the system. ISSU is comparable to
(ISSU) Across performing a controlled High-Availability switchover where the new image is loaded onto the
Major Releases standby CPM which becomes master, and then upgrading the image on the other CPM. Major
ISSU does not apply to 7750 SR-a4/a8/c4/c12. The first (earliest release) possible Major ISSU
upgrade path to Release 13.0 (R4 onwards only) is from Release 12.0.R4 for the 7450 ESS-7/12,
7750 SR-7/12/12e, from Release 12.0.R5 for the 7950 XRS-16c/20, and from Release 12.0.R6
for the 7950 XRS-40.
OOB Management A resilient out-of-band (OOB) management Ethernet redundancy mode has been added to
Ethernet Port SR OS. When the management Ethernet port is down on the active CPM, the active CPM can
Redundancy now use the management Ethernet port of the standby CPM for system management. OOB
management Ethernet port redundancy is enabled using the configure redundancy mgmt-
ethernet-redundancy command.
FIPS-140-2 Release 13.0.R4 introduces the support for FIPS-140-2 Level 1. FIPS (Federal Information
Processing Standards) from NIST (National Institute of Standards and Technology) is a
cryptographic certification standard that defines the requirements for products to become FIPS-
140-2 certified. The feature introduces a new FIPS-140-2 boot mode through a BOF
configuration command that instructs the software to boot up and operate in FIPS-140-2 mode.
When the node is running in FIPS-140-2 mode, it disables the use of cryptographic algorithms
that are not FIPS approved and ensures any FIPS approved algorithms are functioning properly.

New Features
Quality of
Service
Egress Port Congestion monitoring under Egress Port Scheduler (EPS) for Ethernet ports and Ethernet
Scheduler (EPS) Vports is now supported. It can be enabled for PIR rates under egress port scheduler, its levels,
Congestion and groups. Offered rates are constantly monitored and compared to the configured threshold.
Monitoring After the offered rate exceeds the monitoring threshold, the exceed counter is increased. The
operator can use operational commands (show and clear) to monitor the state of the exceed
counter and, from that, derive congestion patterns on EPS.
Prefix Lists for Support has been added to allow SAP ingress and egress QoS policies configured with IPv4
QoS Policies prefix lists for IP criteria matching statements to be applied to the ingress and egress of an SLA
profile. See Enhancements in Release 13.0.R6 for more information.
Routing
Route Policy Release 13.0.R4 supports more policy variables that can be expanded in sub-policy action items.
Variable Action Policy variables such as “@localcomm@” or “@peeras@” can be configured to provide smaller
Items and more efficient policies. The following action items support policy variables: aigp-metric,
as-path-prepend, local-preference, metric, next-hop, damping, origin, preference, tag, and
type. Release 12.0.R1 supports policy variables for as-path, community and prefix-list, and
Release 12.0.R4 adds policy variable support to as-path expression and as-path-group
expression.
OSPF and IS-IS Release 13.0.R4 adds a new method to identify and prioritize certain OSPF and IS-IS routes to
RIB Prioritization be updated in the protocol RIB (Route Information Base) ahead of other, lower-priority routes.
This is enabled through the use of the rib-priority command. This command allows specific
routes to be prioritized through the protocol processing so that updates are propagated to the
RIB (and eventually the FIB) as quickly as possible.
In IS-IS, the rib-priority command is configured within the global IS-IS routing context and
the administrator has the option to either specify a prefix-list or an IS-IS tag value. If a prefix
list is specified, then route prefixes matching any of the prefix list criteria will be considered
high-priority. If, instead, an IS-IS tag value is specified, then any IS-IS route with that tag value
will be considered high priority.
In OSPF, the rib-priority command is configured either within the global OSPF or OSPFv3
routing context or under a specific OSPF/OSPFv3 interface context. Under the global OSPF
context, a prefix list can be specified, which identifies which route prefixes should be
considered high priority. If the rib-priority high command is configured under an OSPF
interface context, then all routes resolved through that interface are considered high-priority.

New Features
The routes that have been designated as high-priority will be the first routes processed and then
passed to the FIB update process so that the forwarding engine can be updated. All known high-
priority routes should be processed before the routing protocol moves on to other standard-
priority routes. This feature will have the most impact when there are a large number of routes
being learned through the routing protocol.
IP MTU on Release 13.0.R4 adds a new command to the network interface (config>router>interface) and
Network and VPRN VPRN network interfaces (config>service>vprn>network-interface) to configure the IP
Network Interfaces maximum transmission unit (MTU) for the associated router IP interface. The command, ip-
mtu mtu-value is the same syntax as previously supported under Layer-3 VPN interfaces.
The configured IP-MTU cannot be larger then the calculated IP-MTU based on the port MTU
configuration.
The MTU that will be used is:
MINIMUM((Port_MTU - EtherHeaderSize), (Configured IP-MTU))
The no form of the command returns the associated IP interfaces MTU to its default value,
which is calculated based on the port MTU setting. (For Ethernet ports this will typically be
1554.)
ECMP Support for In Release 13.0.R4, IP ECMP support has been enhanced to allow up to 64 next-hops per route
64 Next-hops destination. This feature requires chassis mode D and is supported on FP2- and higher-based
line cards on all platforms. This enhancement does not apply to LDP which supports up to 32
ECMP paths.
Enhanced Route Route policies now support more options for matching and manipulating BGP FlowSpec routes.
Policy Support for A new generic extended community syntax allows FlowSpec actions, encoded as BGP extended
BGP FlowSpec communities, to be matched in policy entries and to be added, removed, or replaced by policy
Routes actions. In addition, new flow-spec-source and flow-spec-dest commands allow FlowSpec
routes to be matched on the basis of the IP prefix encoded in the type-1 or type-2 subcomponent
of the FlowSpec NLRI; the matching is applied against a prefix-list.
BGP FlowSpec IPv4 and IPv6 BGP FlowSpec now support an L4 port match encoded in a type-4 subcomponent
Support for L4 of the NLRI. This allows a packet to be matched if either its source TCP/UDP port or its
Port Matching destination TCP/UDP port equals a specific number or falls within one single contiguous range.
Prior to Release 13.0.R4, no filter entry was installed when the FlowSpec route contained a
type-4 port subcomponent.
BGP FlowSpec IPv6 BGP FlowSpec now supports matching IPv6 fragments as encoded in a type 12
Support for IPv6 subcomponent of the NLRI. The implementation complies with draft-ietf-idr-flow-spec-v6-06.
Fragment The following match options are supported: non-first only, first-only, fragment true and
Matching fragment false. Last fragment matching is not supported.
Conditional BGP Release 13.0.R4 introduces the concept of conditional route policy entries to support
Route conditional advertisement of BGP routes. Each conditional policy entry has an expression that
Advertisement tests for the existence or non-existence of certain active IPv4 or IPv6 routes in the route table.

New Features
If the expression evaluates to “true”, then the matching and action commands of the policy entry
are applied as normal. If the expression evaluates to “false”, then the entire policy entry is
skipped and processing continues with the next entry. Note that conditional expressions are only
parsed when the route policy is used as a BGP export policy or a VRF export policy. This feature
is supported in the base router and in VPRNs.
BGP Show Release 13.0.R4 introduces minor changes to various BGP-related show commands to improve
Command visibility and troubleshooting. The show router bgp routes command now uses specific flag
Enhancements values to identify routes that are currently considered “stale” (due to graceful restart) or subject
to “purge” (due to sending route-refresh messages). In addition, the show router bgp summary
command now includes a group filtering option that allows the output to be scoped to a single
configured group.
Segment Routing • The following enhancements have been added to the segment-routing feature:
− OSPF support
− multi-instance support for IS-IS and OSPF with the ability to create a segment-
routing tunnel to a destination prefix reachable in any IGP instance
− ability to create segment-routing tunnels to the same destination prefix in different
IGP instances and using a different SID index/label. This is supported for a
destination prefix reachable over multiple IS-IS instances or over an OSPF instance
and one or more IS-IS instances.
− segment-routing tunnel for IPv4 BGP shortcut and IPv4 BGP label route
− segment-routing tunnel for IPv4 and IPv6 VPRN prefix resolution in both inter-AS
options B and C
Label per Prefix When BGP advertises an IP-VPN route, it distributes an MPLS label with the route. Prior to
for IP-VPN Routes Release 13.0.R4, the MPLS label allocation used one of two methods: label-per-VRF or label-
per-next-hop. Now, a third label allocation mode is supported: label-per-prefix (LPP). Label-
per-prefix is used when a qualifying IP route is exported by a VRF export policy rule that has
the “advertise-label per-prefix” action. A qualifying route is any IPv4 or IPv6 route that is not
a local route, aggregate route, BGP-VPN route, or GRT-lookup static route. With LPP, every
prefix is associated with its own unique label value that does not change while the route is
present in the route table. When the PE receives a terminating MPLS packet with a per-prefix
label value, the packet is forwarded as if the FIB lookup found only the matching prefix route
and not any of the more-specific prefix routes that would normally be selected. LPP supports
ECMP, QPPB, and policy accounting as part of the egress forwarding decision. Note, however,
that it does not support BGP Fast Reroute or BGP sticky ECMP.
RT Constraint for Release 13.0.R4 extends BGP support for constrained VPN route distribution (RT constraint).
L2 VPN and MVPN In previous releases, received RTC routes from a peer had no filtering effect on Layer-2 VPN
Routes routes (BGP-AD, BGP-VPLS, BGP-VPWS) and MVPN-related routes (MVPN-IPv4, MVPN-
IPv6, MCAST-VPN-IPv4) sent to that peer. Now, these other route types are automatically
handled by the same logic that applies to VPN-IPv4, VPN-IPv6 and EVPN routes.

New Features
IPv4 Dynamic ARP The IP routing features are extended with a command that configures the maximum number of
Entry Limit dynamic IPv4 ARP entries that can be learned on an IP interface. When the number of dynamic
ARP entries reaches the configured percentage of this limit set with arp-limit, an SNMP trap is
sent.
When the limit is exceeded, no new entries are learned until an entry expires and traffic to these
destinations are dropped. Entries that have already been learned will be refreshed.
IPv6 Dynamic The IP routing features are extended with a command that configures the maximum number of
Neighbor Entry dynamic IPv6 neighbor entries that can be learned on an IP interface. When the number of
Limit dynamic neighbor entries reaches the configured percentage of this limit set with neighbor-
limit, an SNMP trap is sent. When the limit is exceeded, no new entries are learned until an
entry expires and traffic to these destinations are dropped. Entries that have already been learned
will be refreshed.
IPv6 Neighbor Release 13.0.R4 adds a configurable IPv6 Neighbor Discovery (ND) stale timer value that can
Discovery Stale be set globally or per interface with the stale-time CLI command. The stale timer defines how
Timer long an SR OS node will retain a Neighbor Cache Entry (NCE) that is in the stale state before
it is removed from the cache. The configurable values are 60-65536 seconds, with 14400
seconds being the default.
MPLS
GMPLS UNI Release 13.0.R4 adds the following new functionality to the GMPLS UNI:
• 1:N end-to-end protection of GMPLS LSPs (gLSPs)
BFD on LSPs • Bidirectional Forwarding Detection (BFD) is supported on RSVP LSPs, for both auto LSPs
and manually-configured LSPs. Chassis mode D is required on platforms that support
chassis modes.
Services
MVPN: (C-*,C-*) Release 13.0.R1 introduced the wildcard S-PMSI support for RFC 6513/RFC 6514-based
Wildcard S-PMSI MVPNs with IPv4 PIM in the C-instance and enhanced BSR support for wildcard S-PMSI.
Support for Release 13.0.R4 extends (C-*,C-*) wildcard S-PMSI support and enhanced BSR to support
MVPNs with IPv6 IPv6 PIM ASM/SSM in the C-instance.
PIM in C-instance
MVPN: Receiver- Release 13.0.R1 introduced a new trigger for S-PMSI instantiation: receiver-PE-driven S-PMSI
PE Threshold for instantiation for mLDP and RSVP-TE S-PMSIs in RFC 6513/6514-based MVPNs with IPv4
S-PMSI Trigger PIM in the C-instance. As of Release 13.0.R4, a receiver-PE threshold for the S-PMSI trigger
IPv6 Enhancement functionality is also fully supported with IPv6 PIM ASM/SSM in the C-instance. See Release
13.0.R1 for more information.

New Features
IPv4 PIM ASM Multicast extranet distribution allows multicast traffic to flow across routing instances. The
Mapping for extranet functionality was first introduced in SR OS Release 10.0 for RFC 6037 MVPN and
Multicast Extranet extended in SR OS Release 12.0.R4 to support extranet in RFC 6513/6514 ng-MVPNs, extranet
on Receiver PEs for GRT-source/VRF-receiver, and extranet per multicast group mapping on receiver PE for
RFC 6037 MVPN.
Release 13.0.R4 introduces the support for extranet with IPv4 PIM ASM in a receiver routing
instance in addition to IPv4 PIM SSM. IPv4 PIM ASM extranet is achieved through a local
mapping from the receiver to source routing instances on a receiver PE. The mapping allows
propagation of Anycast RP PIM Register messages between the source and receiver routing
instances. This PIM register propagation allows the receiver routing instance to resolve PIM
ASM joins to multicast sources and to propagate PIM SSM joins over an auto-created extranet
interface to the source routing instance. PIM SSM joins are then propagated towards the
multicast source within the source routing instance.
The following MVPN topologies are supported:
• extranet for RFC 6037 MVPN with MDT SAFI with a local replication on a source PE and
multiple-source/multiple-receiver replication on a receiver PE
• extranet for RFC 6513/6514 ng-MVPN (including RFC 6625 (C-*,C-*) wildcard S-PMSI)
with a local replication on a source PE and a multiple source/multiple receiver replication
on a receiver PE
• extranet for GRT-source/VRF receiver with a local replication on a source PE and a
multiple-receiver replication on a receiver PE
To achieve extranet replication, operator must configure:
• local PIM ASM mapping on a receiver PE from a receiver routing instance to a source
routing instance (config>service>vprn>mvpn>rpf-select>core-mvpn or
config>service>vprn>pim>grt-extranet as applicable)
• Anycast RP mesh between source and receiver PEs in the source routing instance
IMPORTANT NOTES:
• The multicast source must reside in the source routing instance the ASM map points to on a
receiver PE.
• A given multicast group can be mapped in a receiver routing instance using either PIM
SSM mapping or PIM ASM mapping, but not both.
• A given multicast group cannot map to multiple source routing instances.
• Chassis mode D is required on platforms that support chassis modes.
EVPN for MPLS in Release 13.0.R4 introduces the full support for RFC 7432 EVPN. Prior to Release 13.0.R4,
VPLS Services EVPN was only supported for VXLAN tunnels. Now, EVPN can be used in MPLS networks
where PEs are interconnected through any of the following tunnels: RSVP-TE, LDP, RFC 3107
BGP, segment-routing IS-IS or segment-routing OSPF. Similarly to VPRN services, the
selection of the tunnel to be used in a VPLS service (with bgp-evpn mpls enabled) is based on
the auto-bind-tunnel command.
This feature includes the support for:
• the advertisement of MAC/IP advertisement routes as well as Inclusive Multicast Ethernet
Tag routes (for Ingress Replication), according to RFC 7432

New Features
• the configuration of an evi per VPLS service, from which the route-target and route-
distinguisher for the service can be auto-derived; the evi will also be used in the multi-
homing service-carving function
• the control word on EVPN-MPLS packets—the use of the control word can be enabled or
disable on a per-service basis
• the use of force-vlan-vc-forwarding for the transparent transport of the customer 802.1p
bits over the EVPN network
• the integration of EVPN-MPLS destinations with VPLS SAPs and SDP-bindings by
associating them with the same user-configured split-horizon-group
• feature parity with EVPN-VXLAN services.
− MAC mobility, conditional static-MAC protection and MAC duplication detection
− proxy-ARP and proxy-ND
Chassis mode D is required on platforms that support chassis modes.
EVPN Release 13.0.R4 introduces the support for EVPN multi-homing in VPLS services as per
Multi-homing in RFC 7432, including single-active and all-active modes. EVPN multi-homing relies on a new
VPLS Services for logical structure called Ethernet Segment (ES) that is assigned a 10-byte identifier or Ethernet
MPLS Networks Segment Identifier (ESI) and characterizes the multi-homed connectivity between the Customer
Equipment (CE) and the EVPN network.
ES is now supported in Release 13.0.R4 with the following features:
• all-active mode support for CEs connected to the EVPN network through a LAG—This
includes the DF (Designated Forwarder) election, split-horizon and aliasing functions as
per RFC 7432. All-active ES can only be associated to access LAGs.
• single-active mode, including DF election and backup functions as per RFC 7432—Single-
active ES can be associated to ports, LAGs or SDPs.
• DF election-per-service based on the RFC 7432 service-carving function or manual
assignment of DF per service.
EVPN multi-homing is only supported in VPLS services where bgp-evpn mpls is enabled.
Chassis mode D is required on platforms that support chassis modes. See Enhancements in
Release 13.0.R6 for more information.
PBB-EVPN for PBB-EVPN is supported in Release 13.0.R4 according to draft-ietf-l2vpn-pbb-evpn-10. PBB-

I-VPLS and Epipe EVPN is built upon the existing SR OS PBB-VPLS constructs, thereby requiring enabling bgp-
Services evpn mpls in the b-vpls services. In addition to the support of all bgp-evpn mpls features in
the b-vpls services, this feature includes the support for:
• the advertisement of BMAC routes as well as Inclusive Multicast Ethernet Tag routes (for
Ingress Replication) according to draft-ietf-l2vpn-pbb-evpn-10
• the integration of EVPN-MPLS destinations with B-VPLS SAPs and SDP-bindings by
associating them to the same user-configured split-horizon-group
• per-ISID flooding containment in the b-vpls services based on the advertisement of the
local ISIDs and population of MFIBs with the received ISIDs. The configuration of isid-
policy to control the advertisement of the local ISIDs as well as the use of the default
multicast list (as opposed to the per-ISID MFIBs) is also supported.
Chassis mode D is required on platforms that support chassis modes.

New Features
PBB-EVPN Release 13.0.R4 introduces the support for PBB-EVPN multi-homing as per draft-ietf-l2vpn-
Multi-homing in pbb-evpn, including single-active and all-active modes. The following features are now
I-VPLS and Epipe supported:
Services • ethernet-segments associated with I-VPLS SAPs/SDP-bindings and PBB Epipe SAPs.
• use of shared BMACs or per-ES (Ethernet Segment) dedicated BMACs for the traffic
coming from an access ethernet-segment, as per the PBB-EVPN draft
• all-active mode support for CEs connected to the I-VPLS (or Epipe in some scenarios)
through a LAG. This includes the DF (Designated Forwarder) election as in EVPN multi-
homing, split-horizon based on source BMAC checks and aliasing functions as per the
draft. All-active ES can only be associated to access LAGs.
• single-active mode, including DF election and CMAC flush mechanisms defined in the
PBB-EVPN draft. Single-active ES can be associated to ports, LAGs and SDPs for I-VPLS
SAPs/SDP-bindings defined on those objects (Epipe SAPs are also possible in certain
scenarios).
PBB-EVPN multi-homing is only supported in I-VPLS/Epipe services linked to a b-vpls where
bgp-evpn mpls is enabled. Chassis mode D is required on platforms that support chassis modes.
See Enhancements in Release 13.0.R6 for more information.
XMPP Support on Release 13.0.R4 completes the integration of the SR OS routers into the Nuage VSD (Virtual
DC PE for Services Directory) architecture by introducing the Fully-Dynamic XMPP provisioning model
VPLS/VPRN (Fully- for VPRN or VPLS services.
Dynamic Model) Prior to Release 13.0.R4, only the Static-Dynamic model was supported, where the
VPLS/VPRN service itself, as well as most of the parameters, needed to be provisioned
statically through usual procedures (such as CLI and SNMP) and the VSD would dynamically
send the parameters required for the attachment of the VPLS/VPRN service to the L2/L3
domain in the Data Center.
In the Fully-Dynamic model, the entire VPLS/VPRN service configuration is dynamically
driven from VSD and no static configuration is required. Through the existing XMPP interface,
the VSD provides the SR OS routers with a handful of parameters that are translated into a
service configuration by a Python script. This Python script provides an intermediate
abstraction layer between VSD and the SR OS routers, translating the VSD data model into the
SR OS CLI data model.
A MultiCore-CPU CPM (CPM3 or higher) is required to enable XMPP Fully-Dynamic
services. Fully-Dynamic services are not persistent.
Routed-VPLS IPv4 IPv4 multicast routing support in a Routed-VPLS service has been extended to allow the
Multicast multicast sources to be located on the VPLS side of the service with receivers on the IP interface
side of the service.
When IGMP is configured on the IP interface, IGMP-snooping is supported in the VPLS.
This new functionality is not supported for Routed-VPLS services in which VXLAN is enabled.
Multicast VLAN Registration (MVR) functions or the configuration of a video interface are not
supported within the associated VPLS service. IPv4 multicast routing is not supported in Routed
I-VPLS. See Known Issues for more information.

New Features
IPv6 SPI Hashing Release 13.0.R4 introduces SPI hashing for IPv6 traffic over VPLS services for Layer-2 and
for ESP Encrypted Layer-3 VPLS interfaces. The functionality allows a deployed SR OS router (for example, in an
Traffic LTE mobile backhaul network) to use an SPI value from the ESP header of the encrypted tunnel
in hash inputs in addition to Layer-3/4 tunnel IP inputs for better traffic distribution across
multiple ECMP paths/LAG links. SPI hashing can be enabled per service (VPLS) or interface
(Layer-3 services). The hashing configuration applies to traffic ingressing an SR OS router
system on an FP2- or higher-based line card and egressing the system over LAG/ECMP.
IPsec Feature Release 13.0.R4 adds the following feature support on the 7750 SR-c12:
Additions for 7750 • Multi-active tunnel-group
SR-c12
• MC-IPsec
• IPv6 IPsec support
See also Scaling in the Enhancements section.
IPsec: IKEv2 Release 13.0.R4 introduces DHCPv4 based address assignment for IKEv2 remote-access
Internal Address tunnels and allows the user to use an external DHCPv4 server for internal address assignment.
Assignment via SR OS acts as a DHCPv4 client on behalf of the IPsec client and also as a relay agent to relay
DHCP DHCPv4 packet to the server.
IPsec Auto-Update Release 13.0.R4 introduces an automatic mechanism for updating the Certificate Revocation
CRL List (CRL) file. It allows the user to configure up to eight (8) HTTP URLs for a given
ca-profile. The system will try to download the latest CRL from the configured URL based on
a configured schedule. There are two types of schedules:
• periodic—The system will update the CRL periodically at the interval configured using
the command periodic-update-interval. For example, if periodic-update-interval is set
to one (1) day, then the system will update the CRL every one (1) day. The minimum
periodic-update-interval is one (1) hour.
• next-update-based—The system will update the CRL when the time is equal to
Next_Update_time_of_current_CRL minus pre-update-time. For example: if
Next_Update_time_of_current_CRL is 2015-06-30 06:00 and pre-update-time is one (1)
hour, then system will start the update at 2015-06-30, 05:00.
The system will use the URL in configured order, and replace the existing CRL with first-
qualified downloaded CRL. A qualified CRL is a valid CRL and more recent than the existing
CRL.
There following are exceptions to next-update-based scenarios:
• If the current CRL file does not contain a “Next Update” field, system will not schedule
further update.
• If the current CRL file contains a “Next Update” value which is beyond the system limit,
system will not schedule further update.
• At the time when enabling the auto-crl-update, if the configured pre-update-time is
larger than Next_Update_time_of_current_CRL minus system current time, the next
scheduled update time will be set to system current time plus retry-interval.

New Features
IPsec IPv6 Release 13.0.R4 adds the dual-stack support for static LAN-to-LAN IPsec tunnels and IKEv2
Enhancements remote-access tunnels. With this addition, the system now supports both IPv4 and IPv6 traffic
in the same CHILD_SA. For static LAN-to-LAN tunnels, the user can now configure both IPv4
and IPv6 prefixes in the same security-policy entry; for IKEv2 remote-access tunnels, when the
address source (for example, RADIUS or LAA) returns both IPv4 and IPv6 address, the system
will return both to client via the IKEv2 configuration payload.
Video ISA - Release 13.0.R4 introduces the ability to disable FCC/RET client mode. The 7750 SR or 7450
Disable ESS can act as an FCC/RET server as well as a client. By default, the MS-ISA functions as both
Retransimission FCC/RET server and client. The new command enable-rt-client provides the ability to disable
Client the client mode. Disabling the client mode allows the MS-ISA to process higher number of
FCC/RET messages.
Video ISA - A new command, fcc-session-timeout, allows the adjustment of the RTCP session for
Adjustable FCC/RET. By default, an RTCP session remains open for five (5) minutes. The adjustable timer
FCC/RET Timer allows shorter sessions, thereby allowing a higher connectivity rate. Video interface must
remove the accounting policy when fcc-session-timeout is used. Accounting policy with the
video interface is not supported with fcc-session-timeout.
Subscriber
Management
Data-trigger MAC Release 13.0.R4 offers a new MAC learning mechanism for IP-only static host. An IP-only
Learning for static host’s actual data traffic is used for MAC address learning. The data traffic sent must
Static-host match the host’s configured IP-address or the configured IPv6-prefix range.
ESM Host Creation Starting with Release 13.0.R4, ESM host creation via DHCP-snooping is supported for both
via DHCPv6 IPv4 and IPv6 hosts. This feature mainly benefits service providers that use a Layer-3 network
Snooping to aggregate subscribers’ traffic to the BNG. The BNG snoops DHCPv6 messages exchanged
between the subscribers and the DHCP server. A DHCPv6 solicit message will trigger an
authentication request to the AAA server. If the authentication passes, the DHCPv6 reply
message from the DHCP server will trigger the BNG to create an ESM host on the BNG. The
downstream router must be modeled as an IPv6 static host with MAC.
DHCPv6 Filter Release 13.0.R4 introduces a DHCPv6 filter for ESM hosts. ESM hosts created via DHCPv6-
snooping can also benefit from the DHCPv6 filter action “bypass host creation”, which requires
default hosts entries. For example, during a node failure, hosts temporarily fail over to a backup
node and do not require ESM host creation.The hosts can forward traffic via the configured
default host. Furthermore, the DHCPv6 filter has an option to specifically bypass WAN or PD
host creation. Service providers that prefer to share the same /64 among multiple WAN hosts
can choose to bypass WAN host creation option.

New Features
DHCPv6 IA-PD as Release 13.0.R4 enhances DHCPv6 IA-PD modeled as a managed route, such that the managed
Managed Route route can now also point to an IPv4 subscriber host as next hop. For IPoE hosts, it is a
with IPv4 Next Hop prerequisite that ipoe-session is enabled on the group-interface.
The CLI is enhanced to include the next hop type: pd-managed-route [next-hop {ipv4|ipv6}.
See Changed or Deprecated Commands for more information.
IPv6 filters, QoS IPv6 criteria and IPv6 multicast are not supported for DHCPv6 IA-PD as
managed route pointing to an IPv4 subscriber host as next hop. See also the Known Limitations
section.
Local DHCPv6 Release 13.0.R4 adds the support for lease query by client-ID (RFC 5007) to the local DHCPv6
Server Lease server. For security reasons, this must be explicitly enabled via the CLI flag allow-lease-query
Query Support under configure (router | service vprn svc-id) dhcp6 local-dhcp-server server-name. User
identification must be set to DUID (the default) for lease query to work. Lease query by address
is not supported. It is not possible to filter out leases with the link address; the server will always
return all addresses for a client. The Relay Data and Client Link options are not supported and
will not be returned.
WLAN-GW DSM Release 13.0.R4 adds SLAAC and DHCPv6 support to Distributed Subscriber Management
IPv6 Support (DSM). Single authentication per UE is triggered by the first incoming message (DHCPv4,
DHCPv6, Router Solicit or v4/v6 data-trigger). DSM supports any combination of DHCPv4,
DHCPv6 and SLAAC. All existing DSM features are supported, including Lawful Intercept,
AA divert, filters, policers, portal redirect and one-time redirect. IPv6 does not use NAT, and
Wholesale/Retail is supported in order to forward IPv6 traffic in the same VRF as the IPv4 NAT
outside traffic. DSM IPv6 and ESM are not supported on the same vlan-range.
The SLAAC implementation supports DNS signaling (RFC 6106), privacy extensions (RFC
4941), and up to three (3) simultaneously active /128 addresses. The DHCPv6 implementation
supports a single IA_NA address (RFC 3315), optional LDRA encapsulation (RFC 6221) and
DNS signaling (RFC 3646). Stateless DHCPv6 Information Request (RFC 3736) is supported
to allow additional configuration of SLAAC hosts. Solicited and unsolicited router
advertisements (RFC 4861) are supported for both SLAAC and DHCPv6.
On the CPM, a pool manager allocates IPv6 pools to each MS-ISA that can be used in DHCPv6
or SLAAC. The pool manager retrieves these pools via DHCPv6 prefix delegation. Per-UE
allocations are kept locally only on the MS-ISA to maximize performance. The pool manager
enables the support for IOM redundancy and Active/Standby redundancy. The new active MS-
ISA will receive which pools were installed to support forwarding of data-triggered UEs, but
will not allocate new leases for this pool because allocation state was lost. A new pool will be
allocated for new leases. Migration of a data-triggered UE to a new lease is done via prefix
deprecation (SLAAC) or by assigning a new address in a Renew message (DHCPv6). In the
case of Active/Standby redundancy, the pool manager retrieves the old pools using a Lease
Query (RFC 5007).
IPoE Session Release 13.0.R4 adds the following additional capabilities to IPoE session:
Enhancements • multi-chassis redundancy for IPoE sessions active on a retail subscriber interface
• a seamless migration to IPoE sessions by enabling IPoE session on a group interface with
active subscriber hosts. At the next renewal of the DHCP subscriber host, it is attached to

New Features
an IPoE session. Alcatel-Lucent recommends preparing and validating a migration plan in

advance of configuring for this migration.
SHCV policy Release 13.0.R4 introduces policies to control Subscriber Host Connectivity Verification
(SHCV), a mechanism to verify host connectivity to the BNG. There are two types of SHCV
timers: periodic and event-triggered. Prior to Release 13.0.R4, some event-triggered SHCV
relied on the reference timer set by the host-connectivity-verify under the group interface while
others had static values. This so-called “SHCV policy” function in Release 13.0.R4 allows for
the individual configuration of event-triggered SHCV timers and periodic SHCV timers
depending on the application.
Residential Both anti-spoof filters and host-limits can prevent quick Residential Gateway (RG)
Gateway replacement. A BNG anti-spoof filter registers a unique pair of MAC and IP for each SAP. If a
Replacement new replacement RG with a different MAC obtains the same IP address, it will fail the anti-
spoof filter, and all packets from the new RG will be dropped. The BNG has enhanced both
lease-override and SHCV features to allow faster RG replacements. Lease-override
immediately overrides the old DHCP lease with a new one, while an SHCV policy will perform
a connectivity check before removing a host and its lease.
Gx – PCC Rules In addition to existing Gx-based overrides and NAS-filter inserts, Gx functionality on SR OS
routers now supports fully-defined rules that can be constructed on PCRF and applied to the
subscriber host. Fully-defined rules can identify certain type of traffic and apply certain actions
to it. Such fully-defined rules are referred to as Policy and Charging Control (PCC) rules.
Traffic classification (or traffic identification) in the PCC rule is based on the ip-criteria which
includes fields in the IP header such as 5-tuple (any combination of source IP address, source
port, destination IP address, destination port and protocol) and DSCP bits. Multiple actions
associated with such classified traffic within PCC rule are supported:
• ingress or egress rate-limiting
• ingress or egress forwarding-class (FC) change
• ingress next-hop redirect
• ingress service-ID redirect
• ingress HTTP redirect
• ingress or egress gate function
• ingress or egress usage-monitoring
Usage-monitoring for PCC rules is not supported in conjunction with multi-chassis redundancy.
See Limited Support Features and Enhancements for more information.
Gx CCR-t Replays Unanswered CCR-t messages can be periodically replayed during the 24-hour period or until
the response from PCRF is received, whichever comes first. This functionality is enabled via
configuration.
CCR-t replays are used to ensure that the originally-sent CCR-t message eventually reaches
PCRF in case the connectivity between an SR OS node and PCRF was affected at the time when
the subscriber on the SR OS node was terminated.

New Features
Static 1:1 NAT in In static 1:1 NAT, inside IP addresses are predictably mapped to outside IP addresses in 1:1
Protocol Agnostic fashion. This is performed not only for TCP/UDP/ICMP, but for all IP-based protocols. Hence,
Mode static 1:1 NAT is protocol-agnostic.
Port translations for TCP and UDP protocols are not performed, although the flow states based
on 5-tuple are maintained in order to support ALGs.
Traffic can be initiated from outside towards any outside IP address that is already statically
mapped to the inside IP address.
Static 1:1 NAT can be deployed simultaneously with other types of Network Address and Port
Translation (NAPT) via separate pools.
Static 1:1 NAT is supported for LSN44.
NAT – Active- Active-active MS-ISA/MS-ISA2 redundancy model for NAT is now supported in addition to
Active MS-ISA/ existing active-standby model. In active-active redundancy mode, traffic from a failed MS-
MS-ISA2 ISA/MS-ISA2 is distributed to the remaining active MS-ISAs/MS-ISA2s without the need to
Redundancy set aside MS-ISA/MS-ISA2 specifically designated for redundancy purposes and operate it in
Model idle mode during standby operation.
In active-active redundancy model, memory resources are reserved on each MS-ISA/MS-ISA2
in order to accommodate additional translations from failed MS-ISAs/MS-ISA2s. However,
bandwidth is not reserved, and each MS-ISA/MS-ISA2 in the system can operate at full speed
at any given time.
NAT translations are not preserved across the switchover; consequently, traffic from the failed
MS-ISA/MS-ISA2 will need to be re-established.
Recovery Tunnel Release 13.0.R4 adds a new recovery method, recovery tunnel for multi-chassis L2TP LAC
for L2TP LAC redundancy.
Multi-chassis • L2TP tunnel/session information is synchronized between LNS and LAC using L2TP
Stateful failover extension (RFC 4951) after SRRP switchover.
Redundancy
• Two recovery methods (MCS or recovery tunnel) can be specified by CLI (the recovery-
method command under L2TP configuration per routing instance) or new Alc-Tunnel-
Recovery-Method VSA.
• L2TP LNS supports L2TP failover extensions (RFC4951) when initiated by LAC.
Wholesale/Retail Release 13.0.R4 completes the Wholesale/Retail service model with the following additional
Enhancements features:
• multi-chassis redundancy for IPv6 (IPoE and PPPoE)
• SRRP tracking for IPv4 subscriber subnets and IPv6 subscriber prefixes on a retail
subscriber interface—Via routing policies, downstream subscriber traffic can then be
attracted to the master SRRP node to avoid traffic shunting between multi-chassis
redundant nodes.
• overlapping IPv6 prefixes in the retail service for IPoE and PPPoE (enabled with the
private-retail-subnets command on a VPRN retail subscriber interface)—Note that multi-
chassis redundancy in combination with private-retail-subnets is not supported.

New Features
Application
Assurance
Captive Redirect The captive redirect HTTP redirect policy is used to redirect flows without sending any traffic
HTTP Redirect to the Internet unless it matches a configurable whitelist by terminating TCP sessions in the
Policy MS-ISA cards, in which case HTTP flows are redirected to a predefined redirect URL while
non-HTTP TCP flows are TCP reset.
Traffic can be whitelisted using IP address, port number or by using a DNS-IP-cache allowing
traffic to a list of configurable domain names.
OAM
OAM-PM 5-mins Release 13.0.R4 adds the support for a short-duration, five-minute (5-mins), measurement
Measurement interval under the OAM-PM Session configuration. The meas-interval parameter now supports
Interval Support 5-mins, 15-mins, 1-hour and 1-day options.
Release 13.0.R3
Hardware
Support for For 7750 SR-7/12/12e and 7450 ESS-7/12 platforms equipped with CPM5, both the input and
2048kHz Signal on output BITS ports now support G.703 T12 signal format (2048 kHz) in addition to G.703 E12
the CPM5 BITS (E1) and G.703 E11 (DS1) formats. This feature is not supported on CPM4 or earlier versions,
Ports and requires a minimum revision of the CPM5.
Release 13.0.R2
Release 13.0.R2 has no new major features. See also Enhancements in Release 13.0.R2 and
Resolved Issues in Release 13.0.R2.
Release 13.0.R1
The following sections describe the new features added in Release 13.0.R1 of SR OS.
− Hardware
− System
− Quality of Service
− Routing

New Features
− MPLS
− Services
− Subscriber Management
− OAM
Release 13.0.R1 includes features available in Release 12.0.R8. Refer to the SR OS 12.0.R8
Release Notes for features available in Release 12.0.R8, added since Release 12.0.R1.
Hardware The following section describes the new hardware supported in Release 13.0.R1.
4-PORT 100GE Release 13.0.R1 introduces the 4-port 100GE CFP4 Multicore-CPU-based IMM to the Alcatel-
CFP4 IMM Lucent IMM family. The 4-port 100GE CFP4 uses the FP3 chipset, providing the following key
benefits:
• Supports up to 400 Gb/s (full duplex) with SF/CPM5-12e and mini-SFM-12e in 7750
SR-12e, but in order to achieve this level of throughput, the chassis will require all T3-
based IOMs/IMMs
• Supports up to 270 Gb/s throughput when two (2) SF/CPM4-12e and two (2) mini SFM-4
are installed/operational
• Maximum of 128K queues for ingress and 128K queues for egress that can be flexibly
assigned to any port
• Full range of edge services with deterministic performance
• Support for Alcatel-Lucent-sourced CFP4 optic modules (not included)
• LAN and WAN mode support
• Soft Reset support
There are Right-to-Use (RTU) licenses associated with IMM hardware depending on the
licenses.
which an IMM is used. These impedance panels provide highly efficient air flow in support of
the higher performing IOM3-XP/B/C and newer IOM/IMM modules. Note that even when only
one IMM/IOM is deployed, impedance panels are required.
SF/CPM2 and Release 13.0.R1 introduces the support for the following T3-based IOMs, IMMs and ISMs with
SF/CPM3 Support SF/CPM2 and SF/CPM3 in the 7450 ESS-7/12 and the 7750 SR-7/12.
for T3-based Line • IOM3-XP-C
Cards
• 48-Port GE SFP Rev-C IMM
• 12-port 10GE Multicore SFP+ IMM
• 20-port 10GE Multicore SFP+ IMM
• 3-port 40GE QSFP+ + 20-port GE SFP IMM
• 1-port 100GE CFP + 10-port 10GE SFP+ IMM
• 10-port 10GE SFP+ + 20-port GE SFP IMM

New Features
• 1-port 100GE Multicore CFP IMM

• 2-port 100GE Multicore CFP IMM
• 6-port 40GE Multicore QSFP+ IMM
• 1-port 100GE DWDM Tunable IMM
• Multiservice ISM
• Multiservice ISM-E
• MS-ISA2 + 10-port 10GE SFP+ IMM
• MS-ISA2-E + 10-port 10GE SFP+ IMM
• MS-ISA2 + 1-port 100GE CFP IMM
• MS-ISA2-E + 1-port 100GE CFP IMM
There are Right-to-Use (RTU) licenses associated with IMM/ISM hardware depending on the
licenses.
System The following section describes the new system features in Release 13.0.R1.
BFD Soft Reset Release 13.0.R1 adds a new option to the BFD-over-LAG links capability so that the BFD
Control over LAG timers are not extended during a Soft Reset operation on an IOM/IMM/XCM. As a result, BFD
session may time out during the Soft Reset operation and the associated LAG links will be
removed from the operational state. This option should only be used if alternate paths exist and
can be resolved faster then the Soft Reset process can complete. This option is controlled by
including the keywords disable-soft-reset-extension to the config>lag>bfd [disable-soft-
reset-extension] command.
IEEE 1588 With IEEE 1588 messaging is now supported using direct encapsulation in Ethernet frames, as per
Ethernet Annex F of the standard. IEEE 1588 with Ethernet encapsulation is supported on all platforms
Encapsulation and CPMs/CFMs that currently support IEEE 1588 with UDP/IPv4 encapsulation. IEEE 1588
with Ethernet encapsulation requires FP2-based IOMs or IMMs, or newer; it is not supported
with IOM1 or IOM2. IEEE 1588 port-based timestamping (PBT) for Ethernet encapsulation is
supported on all hardware assemblies that currently support IEEE 1588 PBT for UDP/IPv4
encapsulation. This encapsulation mechanism is configured on a per-port basis.
Enforce Use of Release 13.0.R1 introduces the ability to block immediate configuration changes in the CLI
Candidates for configure context. The no immediate configuration under the config>system>management
Configuration CLI context can be used to enforce the use of candidate configuration (and the candidate
Changes commit command) instead of immediate mode line-by-line configuration changes.
Event Handling Release 13.0.R1 introduces a tool that allows operator-defined behavior to be configured on the
System (EHS) router. Event Handling System (EHS) adds user-controlled programmatic exception handling
by allowing a CLI script to be executed upon the detection of a log event (the trigger). Regular
expression matching is available on various fields in the log event to give flexibility in the
trigger definition.

New Features
Filter Policies: Release 13.0.R1 introduces a new type of line card filter policy: ingress IPv4/v6 system policy.
Ingress IPv4/IPv6 Multiple policies can be configured, but only a single active IPv4 system policy and a single
System Line Card active IPv6 system policy can be activated.
Filter Policy The IPv4/IPv6 system filter policy supports the configuration of all IPv4/IPv6 filter policy
match rules and actions, but system policy entries cannot be the sources of mirroring and NAT.
The scale of a system filter policy is identical to a corresponding IPv4 or IPv6 filter policy scale.
A system filter policy cannot be used directly; the active system policy can be deployed by
activating it within any IPv4 or IPv6 exclusive/template filter policy (chaining system policy
and interface policy). When an IPv4 or IPv6 filter policy is chained to the active system filter
policy, system filter rules are evaluated first before any rules of the chaining filter policy are
evaluated (that is, the chaining filter’s rules are only matched against if no system filter match
took place).
Alcatel-Lucent recommends using a system policy with drop/forward actions. Other actions,
such as PBR actions or redirect to ISAs, should not be used unless the system filter policy is
activated only in filters used by services that support such action. Failure to observe this
restriction can lead to undesired behavior as system filter actions are not verified against
services the chaining filters are deployed for.
System filter policies can be populated using CLI/SNMP/NETCONF management interfaces
and OpenFlow policy interface. System filter policy entries cannot be populated using
FlowSpec, RADIUS, or Gx interfaces.
A system filter policy consumes a single set of hardware resources on each line card as soon as
it is activated, regardless of how many IPv4 or IPv6 filter policies chain to that system policy.
System filter policies require chassis mode D.
Filter Policies: Release 13.0.R1 enhances the packet-length support in ingress filter policies by adding support
Packet-length for packet-length condition with drop action for IPv6 filter policies on platforms supporting
Support in IPv6 IPv6 filter policies (the configured packet-length value is matched to Payload Length field in
Filters the IPv6 header).
A filter policy with packet-length condition is not supported in egress directions and on FP1 line
cards. Deploying the filter policy in those scenarios may lead to an unexpected behavior
(packets matching an entry always dropped or always forwarded) and thus should be avoided.
Filter Policies: Release 13.0.R1 introduces the support for IPv4 and IPv6 filter policies on network ports for
VPRN Service- VPRN services. In each VPRN service, an operator can now assign an ingress IPv4 and/or IPv6
aware Network filter policy of scope template that will be applied to unicast traffic arriving on all network
Interface Ingress interfaces for that VPRN (auto-bind-tunnel and explicitly defined spokes). The filter policy is
Filter Policy supported for inter-AS and intra-AS network ports and for any-service label type and any
network transport type. The feature requires network chassis mode D. The feature is not
supported with FlowSpec or Lawful Intercept.
IPv4/IPv6 SPI Release 13.0.R1 introduces SPI hashing for IPv4/IPv6 traffic over VPLS services and Layer-3
Hashing for ESP interfaces. The functionality allows a deployed SR OS router, for example, in an LTE mobile
Encrypted Traffic backhaul network, to use an SPI value from the ESP header of the encrypted tunnel in hash
inputs in addition to Layer-3/4 tunnel IP inputs for better traffic distribution across multiple

New Features
ECMP paths/LAG links. SPI hashing can be enabled per service (VPLS) or interface (Layer-3
services). The hashing configuration will apply to traffic ingressing an SR OS router on an FP2-
and higher-based line card and egressing the system over LAG/ECMP.
Hybrid OpenFlow Release 13.0.R1 introduces the support for VPLS and VPRN service match in OpenFlow flow
Switch (H-OFS): table rules. An OpenFlow controller can specify a VPRN or VPLS service ID as a match
VPLS/VPRN criterion for H-OFS flow table rules. The functionality is achieved through encoding of the
Service Match in SR OS service ID as part of the flow table entry cookie value. A flow table rule with a
Flow Table Rules VPLS/VPRN service ID match is installed on all ingress interfaces of a matched service that
have an ACL policy that embeds a given H-OFS instance. This allows a single H-OFS instance
to contain rules for Layer-2 VPLS services and Layer-3 VPRN services.
Note that the same H-OFS instance can also contain rules for GRT interfaces and system filters.
The feature requires H-OFS with switch-defined-cookie enabled (a multi-service H-OFS).
Hybrid OpenFlow Release 13.0.R1 introduces the support for control of IPv4 and IPv6 System Filter policies using
Switch (H-OFS): OpenFlow. An OpenFlow controller can specify that a given flow table rule applies to system
System Filter filter policies through the encoding of a system policy scope as part of the flow table entry
Policy Match in cookie value. A flow table rule with a system filter scope is installed in all system policies with
Flow Table Rules this H-OFS instance enabled and will apply to any interface that activates a given system policy.
Note that the same H-OFS instance can also contain rules for VPLS/VPRN and GRT interfaces.
The feature requires H-OFS with switch-defined-cookie enabled (a multi-service H-OFS).
Hybrid OpenFlow Release 13.0 introduces the support for port and VLAN ID match in OpenFlow flow table rules
Switch (H-OFS): that also specify a VPLS service ID match. An OpenFlow controller can program an SR OS
Port and VLAN ID Ethernet physical port or a (MC-)LAG in a port match and one of the following:
Match in Flow • an untagged traffic match using standard OpenFlow v1.3.1 flow table match criteria
Table Rules
• a VLAN ID for single-tagged traffic match using standard OpenFlow v1.3.1 flow table
match criteria
• an inner and outer VLAN IDs for dual-tagged traffic match using standard OpenFlow 1.3.1
flow table match criteria and Alcatel-Lucent experimenter match criteria extensions
Masking of port/VLAN values for a flow table match is supported with the exception of adding
a new flow table rule. A flow table rule with port and VLAN match criteria is installed on all
existing VPLS SAPs that match the specified port and VLAN ID values and have an ACL
policy that embeds the H-OFS instance. The feature requires H-OFS with switch-defined-
cookie enabled (a multi-service H-OFS).
Hybrid OpenFlow Release 13.0.R1 introduces the support for Layer-3 (L3) Policy-Based Routing (PBR) for H-
Switch (H-OFS): OFS flow table actions applicable to GRT and VPRN interfaces. OpenFlow controller can
Layer-3 PBR program:
Support • redirect to an IPv4/IPv6 direct/indirect next-hop using OpenFlow v1.3.1 Alcatel-Lucent
experimenter extension
• redirect to GRT or VRF through encoding of “Base” or VPRN service ID in Logical Output
port

New Features
The functionality provided for the above L3 PBR actions when programmed through OpenFlow
is equivalent to L3 PBR when programmed using management interfaces. The feature requires
H-OFS with switch-defined-cookie enabled (a multi-service H-OFS).
Hybrid OpenFlow Release 13.0.R1 introduces the support for Layer-2 (L2) Policy-Based Forwarding (PBF) for H-
Switch (H-OFS): OFS flow table actions applicable to VPLS interfaces. OpenFlow controller can program:
Layer-2 PBF • redirect to a VPLS SAP using standard OpenFlow v1.3.1 protocol and Alcatel-Lucent
Support experimenter extension for dual-tagged SAPs.
• redirect to a VPLS SDP using OpenFlow v1.3.1 Alcatel-Lucent experimenter extension
The functionality provided for the above L2 PBF actions when programmed through OpenFlow
is equivalent to L2 PBF when programmed using management interfaces. The feature requires
H-OFS with switch-defined-cookie enabled (a multi-service H-OFS).
PBR: IPv6 Redirect Release 13.0.R1 introduces the support for IPv6 redirect policies for line card filter policies.
Policy Support Operators can define an IPv6 filter policy by specifying the redirect policy destinations to be
IPv6 addresses and then reference that filter policy in the IPv6 line card filter. A single redirect
policy can only contain IPv6 or (exclusive) IPv4 destinations. An IPv6 redirect policy does not
support SNMP and URL destination tests. All new redirect policy enhancements introduced in
Release 13.0 are also supported for IPv6 redirect policy. An IPv6 redirect policy requires
chassis mode D.
PBR: Enhanced Release 13.0.R1 introduces enhanced VPRN support for redirect policies. Operators can now
Redirect Policy for configure a target routing instance (config>filter>redirect-policy>router) as part of the
VPRN redirect policy. When the target routing instance is configured, the following applies:
• Any supported test configured in a redirect policy is now executed in the routing instance
specified by the redirect policy regardless of the routing instance in which a filter using this
redirect policy is deployed.
When packets are routed to a destination configured in a redirect policy with the router instance
specified (as result of filter match), routing is executed in the router instance context configured
in the redirect policy regardless of the routing context for the interface on which the packet
arrived. Note that if all destinations are down, the forward action is still executed in the routing
instance of the incoming interface and not the routing instance of the redirect policy. If the
hardware does not support the “next-hop router” PBR action, action forward is executed.
PBR: Redirect Release 13.0.R1 allows an operator to configure a unicast route reachability test as part of
Policy Unicast destination tests in a redirect policy. When configured, a destination is eligible for the redirect
Route Reachability policy best-destination selection only when the destination has a route in the RTM within the
Test target routing context of the redirect policy. Redirect policy unicast route reachability test is
supported for both IPv4 and IPv6 redirect policies.
LACP Multiplexing LACP RX/TX independent mode is now supported in Release 13.0.R1. When enabled, LACP
– Independent first enables RX on a LAG link and then sends an indication to the far-end node that it is ready
Control to receive traffic. Upon the reception of this indication, the far-end system can enable TX.
Therefore, in independent RX/TX control, LACP adds a link into a LAG only when it detects
that the other end is ready to receive traffic. This minimizes the traffic loss that might occur in

New Features
coupled mode when a port is added into a LAG before notifying the far-end system or before
the far-end system is ready to receive traffic. Similarly, on link removals from LAG, LACP
turns off the distributing and collecting bit and informs the far-end system about the state
change. This allows the far-end side to stop as soon as possible with sending the traffic.
When adding a port to a LAG in a high-scaled deployment, and that port is the first to be added
to the LAG on that IOM/IMM/XCM, Alcatel-Lucent recommends first shutting down the port,
adding the port to the LAG, then re-enabling the port after a short delay to allow for the
forwarding configurations. This procedure minimizes outages.
RADIUS Challenge In Release 13.0.R1, for enhanced security, SR OS supports RADIUS Access-Challenge
Response authentication method as per RFC 2865.
Authentication
Per-SNMP Release 13.0.R1 introduces the ability to validate SNMPv1 and SNMPv2c requests against per-
Community SNMP-community whitelists (src-access-list) of allowable source IPv4 and IPv6 addresses.
Source IP Address Source IP address lists can be configured then associated with an SNMPv1 or SNMPv2c
Validation community. SNMPv1 or SNMPv2c requests that fail the source IP address or community
validation check are discarded.
Support for On the CPM of the 7750 SR-a4/a8, both the input and output BITS ports now support G.703
2048kHz Signal on T12 signal format (2048 kHz) in addition to G.703 E12 (E1) and G.703 E11 (DS1) formats.
7750 SR-a4/a8
BITS Ports
VMware ESXi The virtualized route reflector (VSR-RR) and virtualized simulator (VSR-SIM) are now
Hypervisor supported on virtual machines created and managed by the VMware ESXi 5.5 hypervisor. This
Support for VSR- adds to the KVM/QEMU hypervisor support introduced in Release 12.0. An Open
RR and VSR-SIM Virtualization Archive (OVA) package containing the SR OS binaries and a starter VSR-RR
configuration is available for download. This OVA package, which contains a VMDK disk
image and OVF file, facilitates the deployment of new VMware virtual machines supporting
VSR-RR or VSR-SIM functionality.
YANG Data Models In Release 13.0.R1, a full YANG data model is provided for all SR OS configuration data (the
for Configuration equivalent of everything under the CLI configure context). The YANG data model is composed
with NETCONF of a set of proprietary Alcatel-Lucent YANG modules that are distributed as part of the SR OS
image file bundle. XML formatted configuration data that conforms to the YANG modules is
supported by the SR OS NETCONF server.
NETCONF XML Release 13.0.R1 introduces the support for XML format content layer requests and responses
Format Content for configuration data. Both <edit-config> and <get-config> NETCONF requests support an
Layer for XML format for the content layer.
Configuration Data

New Features
Release 13.0.R1 Release 13.0.R1 also adds a number of other NETCONF enhancements including:
NETCONF • <edit-config> operations: merge, create, delete and remove
Enhancements
• <copy-config> (for example, from running to startup to get the equivalent of admin save)
• <delete-config> for startup and URL
• <validate> operation and <test-option>
• Equivalent of rollback save and rollback revert
• NETCONF RFC 6241 base 1.1 capability (primarily chunked framing)
Quality of The following section describes the new Quality of Service features in Release 13.0.R1.
Service
Broadcast, Support has been added to allow ingress QoS control of broadcast, unknown and multicast
Unknown, and (BUM) traffic received on a spoke- or mesh-SDP within a VPLS service. The BUM traffic can
Multicast Ingress be separately redirected to policers within an FP ingress network queue group using the per-
QoS Control on forwarding class fp-redirect-group parameter together with broadcast-policer, unknown-
VPLS or policer and mcast-policer within the ingress section of a network QoS policy. The network
Mesh-SDPs QoS policy can be applied to a specific spoke- or mesh-SDP, or to a network IP interface in
which case the control applies to all BUM traffic received on that interface for that forwarding
class (including that received on EVPN bindings).
Prior to Release 13.0.R1, QoS control of the above traffic was combined using fp-redirect-
group multicast-policer, consequently the multicast-policer parameter has been deprecated in
favor of the mcast-policer parameter. See Changed or Deprecated Commands for more
information.
This is supported on FP2- and higher-based hardware.
Ingress QoS Support has been added for ingress QoS control of unicast traffic into a VPRN (including a
Control of Traffic Carrier-Supporting-Carrier VPRN) over automatically-created (using the auto-bind-tunnel
on VPRN Bindings command) or manually-created (using a spoke-sdp command; but not the spoke-sdp command
under the VPRN IP interface context) bindings in a VPRN service.
Unicast traffic received on all automatic and manual bindings in the VPRN can be redirected
per forwarding class to policers in an ingress FP queue group. The traffic from all such bindings
is treated as a single entity (per forwarding class) with respect to QoS control.
This is supported for all available transport tunnel types and is independent of the label mode
(vrf or next-hop) used within the VPRN. IPv4 and IPv6 criteria statements are not supported in
the applied network QoS policy.
The ingress network interfaces on which the traffic is received must be on FP2- or higher-based
hardware. This is ignored on FP1-based hardware.
Queue-depth Queue-depth monitoring has been added in Release 13.0.R1 to give more visibility to the
Monitoring operator of the queue depths being experienced on a set of queues when the traffic is bursty. An
override can be configured on service SAPs or queue group queues to enable monitoring of their
queue depth. The monitoring uses a polling mechanism. The results are presented in the form

New Features
of occupancy ranges of 10% of the queue depth for each configured queue with the percentage
of polls seen in each occupancy range. The occupancy results, together with a clear function,
are available both through a CLI command and SNMP MIB. This is supported on FP2- and
higher-based hardware.
Ingress The ingress classification in a network QoS policy has been enhanced to support both ip-
Classification criteria and ipv6-criteria statements. This classification only applies to the outer IP header of
Using IP Criteria non-tunneled traffic, except for traffic received on a RFC 6037 MVPN tunnel for which
and IPv6 Criteria classification on the outer IP header only is supported. The application of network QoS policies
Statements for with IP or IPv6 criteria statements is only supported on network interfaces. QPPB processing
Network Interfaces takes precedence over this feature.
Routing The following section describes the new routing protocol features in Release 13.0.R1.
Auto-RD A new auto-RD (Route Distinguisher) option has been added to BGP-enabled services. This
feature allows the user to decide whether a manual RD or a system-selected RD is allocated on
a per-service basis. The new option for the RD is available for VPLS, VPRN and Epipe services.
When auto-RD is configured, a type-1 RD will be automatically allocated by the system based
on the configuration of the bgp-auto-rd-range command:
bgp-auto-rd-range ip-addr comm-val 1-65535 to 1-65535
BGP ECMP Release 13.0.R1 enhances the implementation of BGP multipath by introducing the support for
Weighted Load- weighted load-balancing across the ECMP BGP next-hops of an IPv4 or IPv6 route. Weighted
balancing load-balancing allows more traffic to be forwarded to one ECMP next-hop A, compared to a
second ECMP next-hop B, if it is known that the path through A has more available bandwidth
than the path through B. The available bandwidth of a path can be signaled in a BGP route using
a Link Bandwidth extended community.
With the introduction of this feature, SR OS now has the ability to recognize, add, delete, or
replace Link Bandwidth extended communities. A Link Bandwidth extended community can
be added to a BGP route using a BGP export policy, BGP import policy, VRF import policy, or
an EBGP neighbor level command. Weighted load-balancing is performed automatically only
when all the BGP ECMP next-hops of a BGP route carry a Link Bandwidth extended
community.
The use of weighted load-balancing does not change the criteria for different paths to be
considered equal by the BGP decision process for purposes of BGP multipath. Weighted load-
balancing at the BGP next-hop level can be used with weighted load-balancing at the IGP level
if one or more of the BGP ECMP next-hops are resolved by IGP shortcut routes and the LSPs
to a BGP next-hop have different weights. This feature is supported on FP2- and higher-based
hardware.
Route Policy Release 13.0.R1 extends the BGP Fast Reroute functionality to allow route policies to control
Support for BGP whether or not a backup path is calculated and installed for a particular IP prefix. In previous
Fast Reroute releases, the backup path functionality was configurable only per router and per address family.

New Features
With the new route policy control, the backup path can be installed for an IPv4 or IPv6 prefix
if one of the existing router-level commands is configured, or if the best BGP route for the prefix
was matched by a BGP import policy or a VRF import policy with the new install-backup-path
action. This feature does not change the behavior of route types for which backup paths are
supported.
BGP Prefix Limits Release 13.0 adds new flexibility to BGP prefix limits. In previous releases, only one prefix
per Address limit was configurable per BGP neighbor, and this limit applied only to received IPv4 and IPv6
Family unicast routes, prior to any import policy processing. Each address family can now be
configured with its own independent prefix limit, and each address family limit can be evaluated
either at the pre-import policy stage or the post-import policy stage. (A limit applied post-import
does not count received routes that were rejected by the policy.)
Show Route Table Release 13.0.R1 provides a new, extensive output option for the show router route-table and
and FIB Extensive show router fib commands. The existing, non-extensive outputs prior to Release 13.0.R1 do
Outputs not show BGP next-hop detail. The extensive output displays the BGP next-hops of a BGP route
and shows the resolved next-hops of each BGP next-hop in a structured format. .
Cflowd: Multicast In Release 13.0.R1, the Cflowd feature has been expanded to support the sampling and
Sampling Support processing of multicast IP flows. If enabled, multicast flows will be subject to traffic sampling
based on the sampling rate, just as unicast traffic would be sampled. Multicast flow statistics are
then sent to the Cflowd collector using existing IPv4 and IPv6 templates; however, two new
fields will be added to report the multicast replication factor (field ID 99) and a flag indicating
that the flow was a multicast flow. When multicast sampling is enabled, this feature does not
include the sampling of multicast control plane traffic destined to the CPM/CFM.
See Changed or Deprecated Commands for more information about changed commands.
Cflowd: Addition In Release 13.0.R1, two new fields, MPLS_TOP_LABEL TYPE (field ID 46) and
of FEC Address to MPLS_TOP_LABEL_ADDR (field ID 47), have been added to the MPLS-related templates for
MPLS Templates Cflowd formats v9 and v10. These fields can be used to show the far-end IP address for the top
MPLS label as well as the protocol source of this transport label. SR OS will only report the far-
end IP address for LDP sourced MPLS labels (all other sources will result in a null value in both
fields) and only supported on ingress sampling at the LSR routers.
Empty Prefix Lists In Release 13.0.R1, it is now possible to configure a prefix-list which is empty (containing no
in Router Policy member prefixes) in router policies, which will evaluate as if “no match” was found when
referenced in a policy. When removing member prefixes from a prefix-list, the latter will no
longer be automatically removed when the last member is removed. If required, the empty
prefix-list must be explicitly removed by the operator.
IS-IS ATT Release 13.0.R1 enables the configuration of IS-IS to suppress setting the attached bit (ATT) on
(Attached) Bit originated Level-1 LSPs, to prevent all Level-1 routers in the area from installing a default route
Suppression to the router which the command is configured and which originates the LSPs.

New Features
IS-IS Single IS-IS interoperability has been extended to enable a non-multi-instance (MI) capable router to
Instance Router in establish an adjacency in its standard instance zero (0) with an SR OS router in a non-zero
a Non-Zero instance. See Enhancements in Release 13.0.R4 for more information.
Instance
IPv6 MCAC Policy Release 13.0.R1 extends the existing MCAC policy support by adding the support for IPv6
with Source MCAC policies, including source awareness. The IPv6 MCAC is supported for PIM and MLD.
Awareness See Enhancements in Release 13.0.R4 for more information.
Support
Multipoint LDP Release 13.0.R1 enhances the support for in-band mLDP signaling for IPv6 multicast. The
In-band Signaling following enhancements are added atop of the existing functionality (IPv4 PIM SSM with in-
Enhancements for band IPv4 P2MP mLDP signaling in the “Base” routing instance).
IP Multicast • Support for IPv6 SSM PIM with in-band IPv4 P2MP mLDP signaling for IP multicast in
in GRT the “Base” routing instance as per RFC 6826: Multipoint LDP In-Band Signaling for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.
• Support for OAM p2mp-lsp-ping for all the above in-band mLDP signaling use cases.
Route Policy In Release 13.0.R1, the policy variable expansion functionality is extended with midstring
Midstring Variable variable expansion for global policy objects. Policy variables such as “peer-@asname@” or
Expansion “comm-@peeras@-highpref” can be configured to provide smaller and more efficient policies.
Release 12.0 supports policy variables contained completely in the name, such as
“@localcomm@” or “@peeras@”. The following global policy objects support midstring
variable expansion: as-path, as-path expression, as-path-group, as-path-group expression,
community, and prefix-list.
Route Policy Release 13.0.R1 extends the Add-Path functionality to allow route policies to control the
Support for BGP number of advertised paths per prefix or NLRI. In previous releases, the maximum number of
Add-Path paths to send was controllable only per neighbor and per address family; this could result in
sending more total paths to a peer than necessary if only some prefixes require a higher number
of paths. With the new route policy control, the maximum number of paths to send for an IPv4
or IPv6 prefix is based on the setting applied by a BGP import policy to the best BGP route for
the prefix.
Route Policy Route policies have been extended to support more general matching of extended communities
Support for in BGP routes. In prior releases, only the following types of extended communities could be
Matching Any matched: route target, route origin, and origin-validation state. A new extended community
Type of BGP syntax allows for matching specific hexadecimal values in the type/sub-type and value fields of
Extended an extended community. In Release 13.0.R1, the new matching functionality is supported only
Community with IP and IP-VPN routes.

New Features
Segment Routing: Segment routing adds to IS-IS routing protocol the ability to perform shortest-path routing and
Single IS-IS source routing using the concept of abstract segment. A segment can represent a local prefix of
Instance, LFA, a node, a specific adjacency of the node (interface or next-hop), a service context, or an explicit
Link-protect path over the network. For each segment, the IGP advertises an identifier referred to as
Remote LFA Segment ID (SID).
When segment routing is used together with MPLS data plane, the SID is a standard MPLS
label. A router forwarding a packet using segment routing will thus push one or more MPLS
labels.
Segment routing using MPLS labels can be used in both shortest-path routing applications and
in traffic-engineering applications. The scope of this feature is the shortest-path forwarding
application.
When a received IPv4 prefix SID is resolved, the Segment Routing module programs the
Incoming Label Map (ILM) table with a swap operation and also the Label to NHLFE (LTN)
table with a push operation both pointing to the primary/LFA NHLFE. An IPv4 segment-
routing tunnel to the prefix destination is also added to the Tunnel-Table Manager (TTM).
The segment-routing tunnel in the TTM is available to be used in the following contexts:
• VLL, LDP VPLS, IES/VPRN spoke-interface, R-VPLS, BGP-EVPN.
• BGP-AD VPLS, BGP-VPLS, BGP VPWS when the use-provisioned-sdp option is
enabled in the binding to the PW template.
• Intra-AS BGP VPRN for VPN-IPv4 and VPN-IPv6 prefixes with both auto-bind-tunnel
and explicit SDP.
• Multicast-over-IES/VPRN spoke interface with the spoke-SDP riding a segment-routing
tunnel.
• OAM: ping and traceroute within VPRN and SDP keepalive.
Segment routing introduces the remote LFA feature which expands the coverage of LFA by
computing and automatically programming segment-routing tunnels which are used as backup
next-hops. The segment-routing shortcut tunnels terminate on a remote alternate node which
provides loop-free forwarding for packets of the resolved prefixes. When the loopfree-
alternate option is enabled in an IS-IS instance, segment-routing tunnels are protected with an
LFA backup next-hop. If the prefix of a given segment-routing tunnel is not protected by the
base LFA, the remote LFA functionality will automatically compute a backup next-hop using a
segment-routing tunnel if the remote-lfa option is also enabled in the IGP instance.
MPLS The following section describes the new MPLS features in Release 13.0.R1.
GMPLS UNI Release 13.0.R1 introduces the Generalized Multiprotocol Label Switching (GMPLS) User-to-
Network Interface (UNI). The GMPLS UNI permits dynamic provisioning of optical transport
connections between IP routers and optical network elements in order to reduce the operational
time and administrative overhead required to provision new connectivity. The
7750 SR-7/12/12e and 7950 XRS support the role of a client side of the GMPLS UNI, with an
optical cross-connect, or photonic switch, such as the Alcatel-Lucent 1830 PSS playing the role
of the network side. Release 13.0.R1 supports the Link Management Protocol (LMP) for
managing gray Ethernet data bearers, and RSVP-TE signaling for GMPLS LSPs, over an out-
of-band IP control channel (IPCC). End-to-end protection of GMPLS LSPs using load

New Features
balancing and full reroute is supported. The 7750 SR-7/12/12e and 7950 XRS also support the
signaling of GMPLS LSP constraints such as the optical path, bandwidth, optical segment
protection type, and SRLG. SRLG collection is also supported. These GMPLS UNI features
support use cases including dynamic connection setup with constraints and multi-layer
resiliency. See Enhancements in Release 13.0.R4 for more information.
LDP IPv6 Using Release 13.0.R1 introduces the support of IPv6 in LDP control and data planes. The SR OS LDP
128-bit LSR-ID IPv6 implementation uses a 128-bit LSR-ID as defined in draft-pdutta-mpls-ldp-v2. The
following capabilities are supported:
• link- and targeted-LDP adjacency/session using IPv6 128-bit LSR-ID
• concurrent 32-bit LSR-ID IPv4 and 128-bit LSR-ID IPv6 LDP link adjacency and session
over the same link
• support of downstream-unsolicited (DU) label distribution
• ability to advertise and resolve unicast IPv4 FEC, unicast IPv6 FEC, mLDP IPv4 FEC
(opaque types 1, 3, and 250, with IPv4 root LSR address), mLDP IPv6 FEC (opaque types
4 and 251, with IPv4 root LSR address), and service FECs on IPv6 LDP session
• ability to advertise and resolve a unicast IPv6 FEC on a 32-bit LSR-ID IPv4 LDP session
• support of the LDP session capability advertisement TLV along with the Dynamic
Capability Announcement TLV
• global and per-peer FEC filter policies for IPv6 prefixes
• IPv6 FEC prefix origination using the fec-originate option
• configuring the local-lsr-id option for link-LDP (I-LDP) IPv6 interface and targeted-LDP
(T-LDP) IPv6 session
• LDP synchronization with IS-IS, OSPFv3 and with static IPv6 routes
• enabling BFD for T-LDP and LDP sessions
• LDP SDPs with far-end and tunnel-far-end using IPv6 addresses or a mix of IPv4 and
IPv6 addresses
• using an LDP prefix IPv6 FEC as a shortcut for IGP IPv6 prefixes (config>router>ldp-
shortcut)
• using an LDP prefix IPv6 FEC to resolve the indirect next-hop of a static IPv6 route
• Epipe VLL, VPLS, IES/VPRN spoke-interface, R-VPLS
• PW redundancy within Epipe/Ipipe VLL, Epipe spoke termination on VPLS/R-VPLS and
IES/VPRN
• mirroring service and LI
• OAM tools: sdp keep-alive, sdp-ping, sdp-mtu, lsp-ping, lsp-trace, vccv-ping and vccv-
trace for single-hop FEC128 PW
The LDP IPv6 feature is supported on all platforms with FP2- or higher-based hardware in
chassis mode D.
SRLG Weight for Release 13.0.R1 introduces the ability to specify a penalty weight associated with an SRLG. The
Bypass and likelihood of paths with links sharing SRLG values with a primary path being used by a bypass
Detour LSP or detour LSP can be configured if a penalty weight or penalty cost is specified for the link. The

New Features
higher the penalty weight, the less desirable it is to use the link with a given SRLG. Penalty
weights are configured in CLI using a new penalty-weight option in the config>router>if-
attribute>srlg-group group-name context.
Weighted Load- Release 13.0.R1 introduces the ability to spray flows of IGP, BGP, and static-route prefixes
Balancing over resolved to a set of ECMP tunnel next-hops proportionally to the weights configured for each
MPLS LSP MPLS LSP in the ECMP set.
Weighted load-balancing is supported in the following forwarding contexts.
• IGP prefix resolved to IGP shortcuts in the Route Table Manager (RTM) (rsvp-shortcut or
advertise-tunnel-link enabled in the IGP instance).
• BGP prefix with the BGP next-hop resolved to IGP shortcuts in the RTM (rsvp-shortcut
or advertise-tunnel-link enabled in the IGP instance).
• Static-route prefix resolved to an indirect next-hop which itself is resolved to a set of equal-
metric MPLS LSPs in the Tunnel-Table Manager (TTM).
• Static-route prefix resolved to an indirect next-hop which itself is resolved to IGP shortcuts
in the RTM.
• BGP prefix with a BGP next-hop resolved to a static route which itself resolves to set of
tunnel next-hops towards an indirect next-hop in the RTM or TTM.
• BGP prefix resolving to another BGP prefix which next-hop is resolved to a set of ECMP
tunnel next-hops with a static route in the RTM or TTM or to IGP shortcuts in the RTM.
The weighted load-balancing feature is not supported for a BGP prefix with the BGP next-hop
resolved in the TTM to RSVP LSPs (BGP shortcut).
Note that this feature does not modify the route calculation; thus, the same set of ECMP next-
hops is computed for a prefix. It also does not change the hash routine: only the spraying of the
flows over the tunnel next-hops is modified to reflect the normalized weight of each tunnel next-
hop.
As part of this feature, the static-route implementation has been enhanced to support ECMP
over a set of equal-cost MPLS LSPs. The user can allow automatic selection or specify the
names of the equal-metric MPLS LSPs in the TTM to be used in the ECMP set.
The weighted load-balancing feature is supported on all platforms with FP2- or higher-based
hardware in chassis mode D.
Enhanced Auto- Release 13.0.R1 introduces a new auto-binding framework for selecting tunnels in the Tunnel-
Binding to Tunnels Table Manager (TTM) in the following resolution contexts:
• resolution of a static route prefix using tunnels to an indirect next-hop
• resolution of a BGP prefix using tunnels to a BGP next-hop (BGP shortcut)
• resolution of RFC 3107 BGP label route prefix using tunnels to a BGP next-hop
• resolution of a VPN-IPv4 or VPN-IPv6 prefix to a BGP next-hop
The user configures the resolution option to enable auto-bind resolution to tunnels in the TTM.
If the resolution option is explicitly set to disabled, the auto-binding to tunnel is removed.

New Features
If resolution is set to any, any supported tunnel type in the resolution context will be selected
following the TTM preference. The following tunnel types are selected in order of preference:
RSVP, LDP, Segment Routing, BGP, and GRE. The user can configure the preference of the
segment-routing tunnel type in TTM for a specific IGP instance.
If one or more explicit tunnel types are specified using the resolution-filter option, then only
these tunnel types will be selected again following the TTM preference.
The user must set resolution to filter to activate the list of tunnel-types configured under
resolution-filter. In the context of a static route, the user can further explicitly configure the
MPLS LSP names to use for the resolution of the indirect next-hop.
The existing auto-binding commands for the above resolution contexts are deprecated; see
Changed or Deprecated Commands for more information. When a router is upgraded to Release
13.0, the commands are automatically converted into the new format.
Services The following section describes the new services features in Release 13.0.R1.
ARP/ND Snooping Release 12.0 introduced support for the proxy-ARP function for VPLS services, where IP-
and Proxy Support >MAC pairs advertised by EVPN can populate a proxy-ARP table per service, so that local ARP
requests can be responded by the SR OS node. In Release 13.0.R1, the following enhancements
have been added:
• In addition to the proxy-ARP function, a proxy Neighbor Discovery (proxy-ND) function
for VPLS services is introduced, so that local IPv6 Neighbor Solicitation (NS) messages
can be replied by the SR OS node.
• The proxy-ARP/ND table per service can be populated not only by EVPN-received IP-
>MAC entries, but also by:
− Dynamic entries, snooped from ARP/GARP/NA messages being sent by the
routers/hosts attached to local SAPs/SDP-bindings.
− Static-entries configured in the proxy-ARP/ND tables.
• If EVPN is enabled, the snooped dynamic entries or configured static entries are advertised
in EVPN MAC routes that contain the IP->MAC pairs.
• New options to enable or disable the flooding of ARP and ND packets in an EVPN network
have been added (ND includes Neighbor Solicitation (NS) and Neighbor Advertisement
(NA) packets). In an EVPN network, where all CEs connected to SAPs/SDP-bindings are
routers and they send unsolicited GARP/NA messages, disabling the flooding of ARP/ND
messages may help reduce the flooded traffic significantly. This assumes proxy-ARP/ND is
enabled in all PEs and remote PEs send unsolicited GARP/NA messages to local CEs when
they receive EVPN IP->MAC advertisements.
• A duplicate-detect mechanism is added so that an ARP/ND spoofing attack or a
misconfigured duplicated IP address can be detected. This feature will warn the user of the
presence of a duplicate IP address, and optionally will advertise an anti-spoofing MAC
address for the duplicate IP. The anti-spoofing MAC address will normally be dropped at
the ingress SAPs/SDP-bindings through user-configured filters that will block any
potential man-in-the-middle attack.
See Known Limitations for restrictions that apply.

New Features
MVPN: (C-*,C-*) Release 13.0.R1 introduces the support for (C-*,C-*) wildcard S-PMSI for RFC 6513- and RFC
Wildcard S-PMSI 6514-based MVPNs with mLDP or RSVP-TE in the P-instance and IPv4 PIM SSM and ASM
Support for in the C-instance.
MVPNs Wildcard S-PMSI allows the use of a selective tunnel as default tunnel. This ensures that a full
mesh of LSPs is no longer required between MVPN PEs, reducing related signaling states and
BW consumption for multicast distribution (no traffic is sent to the PEs without receivers
active). Wildcard S-PMSI MVPN deployments support existing MVPN functionalities,
including extranet, UMH redundancy, LSP templates, MPLS FRR, Multicast Source Geo-
Redundancy, and receiver-PE threshold for S-PMSI trigger (new in Release 13.0).
The SR OS implementation is compliant with RFC 6625: Wildcards in Multicast VPN Auto-
Discovery Routes. SR OS (C-*,C-*) wildcard implementation uses wildcard S-PMSI instead of
I-PMSI for a given MVPN; thus, the following processing takes place:
• the source PE advertises an I-PMSI Auto-Discovery (A-D) route without the tunnel
information present—encoded as per RFC 6513 and RFC 6514 prior to advertising
wildcard S-PMSI
• the source PE advertises an S-PMSI A-D route whose NLRI contains the (C-*,C-*)
wildcard with the tunnel information encoded as per RFC 6625
• the receiver PE joins the wildcard S-PMSI if there are any receivers present
If the source PE does not encode I-PMSI/S-PMSI A-D routes as per the above, or advertises
both I-PMSI and wildcard S-PMSI with the tunnel information present, no interoperability can
be achieved.
MVPN: Enhanced Release 13.0.R1 introduces enhanced BSR signaling for MVPNs with the wildcard S-PMSI
BSR Support for functionality. To ensure the proper BSR operation between MVPN PEs, the operator can select
Wildcard S-PMSI two BSR modes in the P-instance (config>service>vprn>mvpn>pt>inclusive):
• bsr unicast: the BSR PDUs are sent or forwarded as unicast PDUs when I-PMSI with a
pseudo tunnel interface is installed. BSR PDUs received on the I-PMSI pseudo-tunnel
interface are also processed as unicast packets—thus, no special state needs to be created
for BSR when (C-*,C-*) is enabled. This is the default and recommended mode.
• bsr spmsi: an optional full mesh of S-PMSI tunnels is created between PEs in the MVPN
to exchange BSR PDUs. This mode is optional to allow interoperability with other vendor
equipment.
Enhanced BSR support for wildcard S-PMSI currently only supports IPv4.
MVPN: Multipoint Release 13.0.R1 enhances the support for in-band mLDP signaling for IP multicast in MVPN.
LDP In-band Previously, this functionality was only supported in the Base routing instance.
Signaling • Support for IPv4 and IPv6 SSM PIM with in-band IPv4 P2MP mLDP signaling for IP
Enhancements multicast in a VPRN service as per RFC 7246: Multipoint Label Distribution Protocol In-
Band Signaling in Virtual Routing and Forwarding (VFR) Table Context.
• Support for OAM p2mp-lsp-ping for all the above in-band mLDP signaling use cases.

New Features
MVPN: Receiver- Release 13.0.R1 introduces a new trigger for S-PMSI instantiation. Operators can optionally
PE Threshold for enable receiver-PE-driven S-PMSI instantiation for mLDP and RSVP-TE S-PMSIs in RFC
S-PMSI Trigger 6513- and RFC 6514-based MVPNs. In addition to the existing bandwidth (BW) threshold, two
new threshold values are defined: S-PMSI receiver PE add threshold and S-PMSI receiver PE
delete threshold (expected to be significantly higher).
When a (C-S,C-G) crosses a BW threshold to create an S-PMSI tunnel, instead of the regular
S-PMSI signaling, the sender PE originates S-PMSI explicit tracking procedures to detect how
many receivers PEs are interested in a given (C-S,C-G). When the receiver PEs receive explicit
tracking request, each responds indicating whether there are multicast receivers present for that
(C-S,C-G) on the given PE (PE is interested in a given (C-S,C-G)). The source PE can thus
determine how many receiver PEs are interested in a given (C-S,C-G) and trigger an S-PMSI
creation if the number of PEs is no larger than the add threshold. The created S-PMSI tunnel is
signaled with explicit tracking, so the source PE can detect when the receiver PE number
increases and move the given (C-S,C-G) multicast flow back on a default PMSI (I-PMSI or
wildcard S-PMSI). The explicit tracking procedures follow RFC 6513 and RFC 6514 with
clarification and wildcard S-PMSI explicit tracking extensions, as described in IETF Draft:
draft-dolganow-l3vpn-expl-track-00.
See New Features in Release 13.0.R4 for more information.
EVPN for IPv6 Release 13.0.R1 brings the support of IPv6 host and IPv6 prefixes in EVPN. The system can
Host and Prefixes now send and receive MAC/IP advertisement routes that can be used along with the proxy-nd
function to optimize the neighbor discovery key functions in the service. In addition, when
ip-route-advertisement is enabled in an R-VPLS, EVPN may now advertise/process IPv6
prefixes encoded in the BGP-EVPN IP-prefix routes.
IGMP-snooping on Release 13.0.R1 adds support for IGMP-snooping in EVPN-VXLAN VPLS services. When
EVPN-VXLAN IGMP-snooping is enabled, IGMP reports will be snooped on SAPs/SDP-bindings and also on
VXLAN bindings. This feature is not supported in EVPN-VXLAN R-VPLS services.
IKEv2 Internal Release 13.0.R1 introduces a local address assignment method for IKEv2 remote-access tunnel.
Address This feature allows the system to request an IPv4 or IPv6 address from an address pool
Assignment via configured in a local DHCPv4 or local DHCPv6s server for a remote-access tunnel client. The
Local Pool address is assigned via an internal API call directly without any actual DHCP exchange. This
feature supports auth-method psk/psk-radius/cert/cert-radius/eap. For auth-method that
involves RADIUS, such as psk-radius and cert-radius, the system will perform RADIUS
authentication before address assignment, and if local address assignment is enabled, the
address information returned in RADIUS access-reply will be ignored.
GRE Tunnels over Release 13.0.R1 extends the ISA-tunnel support of IP/GRE tunneling to allow either IPv4 or
IPv6 Transport IPv6 to be used as the transport/delivery protocol for a tunnel; in previous releases, only IPv4
transport was supported. When IPv6 transport is used, the GRE-encapsulated packets have an
outer IPv6 header and the public endpoints of the tunnel are anchored by IPv6 addresses. A GRE
tunnel using IPv6 transport can carry IPv4 and/or IPv6 packets as payload.

New Features
IPsec • Release 13.0.R1 introduces a new certificate reload command option:

Enhancements admin>certificate>reload type cert-key-pair, which allows the user to reload a
configured certificate and its corresponding key file at the same time.
• In Release 13.0.R1, the system can optionally generate a warning message before a
certificate or a CRL expires. The amount of time before expiration is configurable via two
system wide CLI commands (certificate-expiration-warning and crl-expiration-
warning). Using the repeat command, the warning message can optionally be configured
to repeat at a specified interval.
• In Release 13.0.R1, the system supports RADIUS interim update message for the IKEv2
remote-access tunnel. The RADIUS attributes in interim-update are the same as acct-start,
except for one attribute Acct-status-type; the value of Acct-status-type in acct-start is 1;
while in interim-update is 3. In Release 13.0.R1, if accept-coa is configured, then the
system will accept the disconnect-request message (RFC 5176) and tear down the specified
IKEv2 remote-access tunnel. The identification of the tunnel could be one of following:
− Acct-Session-Id
− Nas-Port-Id + Framed-Ip-Addr/Framed-Ipv6-Prefix + Alc-IPSec-Serv-Id
− User-Name
• In Release 13.0.R1, for IKEv2 tunnels, IKEv2 IDi values (along with types) are added into
the output of the following show commands:
− show ipsec gateway tunnel
− show ipsec gateway gw-name tunnel
− show ipsec gateway gw-name tunnel ip:port
The user could also filter the output via IDi by specifying a new parameter idi-value with
the following command:
− show ipsec gateway [name name] tunnel idi-value idi-prefix
Note that idi-prefix is used as a prefix; the system will show every tunnel that has the IDi
with that prefix.
The user can also filter the output via private interface’s address type with the following
command:
− show ipsec gateway tunnel [private-address-type {ipv4 | ipv6 | dual-stack}]
This filtering is to display remote-access tunnels that are using IPv4-only, IPv6-only, or
IPv4+IPv6 (dualstack) addresses only. Without the private-address-type filter, the output
will display all tunnels.
IPsec IPv6 Release 13.0.R1 introduces the IPv6 support for IPsec tunnel encapsulation; the system allows
Enhancements IPv4 or IPv6 traffic to be encapsulated in an IPv6 IPsec ESP tunnel. IKEv1 and IKEv2 protocol
could also run over IPv6 UDP. IPv6 fragmentation and reassembly for IPv6 ESP/IKE packets
are also supported.
PW-SAP for Epipe Release 13.0.R1 extends PW-SAPs to Epipe VLL services, so that QoS policies can be managed
VLL Services at a central PE/BNG. PW-SAPs on an Epipe VLL can be mated to an Ethernet SAP or a
spoke-SDP in the same service. This release also adds the support for BGP 3107 tunnels for the
PW port, in addition to the existing RSVP LDP LSP support.

New Features
SAP The following enhancements have been added on QinQ ports in Release 13.0.R1:
Enhancements on • A new SAP “*.null” may now be defined in a QinQ port. This SAP will function as a
QinQ Ports default SAP for single-tagged frames in a QinQ port. It will accept single tags in the range
0 to 4095 as well as untagged traffic.
• A new SAP “*.*” may be defined in a QinQ port. It will function as a default SAP for
double-tagged frames in a QinQ port. This new SAP will accept untagged, singly-tagged,
and doubly-tagged frames with tags in the range 0 to 4095.
• SAPs type :X.0 and :X.* as well as :0.* and the new SAPs mentioned above can be
supported in the same QinQ port as well as in the same (VPLS) service.
The above three enhancements are enabled at system level by the config system ethernet new-
qinq-untagged-sap command. Note that this behavior is always enabled on the 7950 XRS and
cannot be turned off.
When a new frame arrives at a QinQ port on a system enabled for this new behavior, a SAP
lookup is performed and the frame will be assigned to the highest priority SAP that matches the
tag values encoded in the frame. When 0.*, *.null and *.* are configured on the same port, the
priority order is:
1. 0.*
2. *.null
3. *.*
For example, the SAP lookup for untagged frames will yield 0.* if the three above SAPs are
defined on the same port. If 0.* is not defined on the port, *.null will have higher priority than
*.* and will be selected.
The new *.null and *.* SAPs are supported on Epipe, PBB-Epipe, VPLS, and I-VPLS services
on access and hybrid ports or LAGs. This feature requires chassis mode D.
UP MEP and VPLS By default, an Ethernet SAP configured over a LAG will be removed from the forwarding plane
LAG SAP when the LAG is operationally down. This can affect control protocols extracted on egress,
Interaction specifically CFM UP MEPs. The process-cpm-traffic-on-sap-down command allows the
broadcast, unknown and multicast traffic to reach the egress and applicable control traffic to be
extract to and processed by the CPM/CFM.
IP Interface In previous releases, IP-interface-level statistics were not collected for the IP interface
Statistic Collection associated with an R-VPLS service.
on R-VPLS Beginning with Release 13.0.R1, IP-level statistics will be collected for the IP traffic that is
Services routed through the IP interface associated with the R-VPLS service. Layer-2 traffic that is
bridged as part of the VPLS portion of the service is not counted. The IP-interface-level
statistics are populated in the IF-MIB (IfEntry and IfXEntry tables) and TiMetra-vRtr-MIB
(vRtrIfStatsEntry table).
IP statistics are only accounted on traffic arriving on a service access point (SAP). IP level
statistics are not collected for egress multicast IP traffic that is routed through the associated IP
interface.
VCCV BFD Release 13.0.R1 adds Virtual Circuit Connectivity Verification (VCCV) using BFD (VCCV
BFD) to LDP VPLS mesh SDPs. VCCV BFD was originally introduced in Release 12.0.R4.

New Features
Subscriber The following section describes the new Subscriber Management features in Release 13.0.R1.
Management
Diameter NASREQ Release 13.0.R1 adds the support for Diameter Network Access Server Requirements
Authentication (NASREQ) application that can be used for subscriber-host authentication and authorization.
The stateless NASREQ implementation supports AA-Request (AAR) and AA-Answer (AAA)
messages only. Subscriber-host authentication and authorization data accepted in an AAA
message include IP configuration (address/prefix, pool names, DNS servers), framed routes,
MSAP details, retail service, subscriber ID and profile strings (such as SLA or subscriber). The
authentication data is included using existing RADIUS attributes carried as Diameter AVPs.
Diameter NASREQ authentication is supported for dual stack IPoE and PPPoE PTA in a routed
CO model.
Python Support Release 13.0.R1 adds the Python support for Diameter NASREQ application messages:
for Diameter AA-Request (AAR) and AA-Answer (AAA). See Enhancements in Release 13.0.R4 for more
NASREQ information.
Application
Messages
Diameter Multi- Diameter multi-chassis redundancy is introduced through the concept of Diameter Proxy.
Chassis Diameter Proxy is instantiated on two 7750 SR nodes; one of the 7750 SR nodes assumes the
Redundancy active state, while the other node assumes the standby state. The active Diameter Proxy
transparently passes messages between the Diameter clients and the DRA/PCRF. Only the
active Diameter proxy allows peering connections – from the Diameter client and towards the
Diameter server (DRA/PCRF). The standby Diameter Proxy does not accept or initiate any
peering connections. This concept allows the redundant pair of 7750 SR nodes to assume a
single Diameter Identity (host-name and diameter realm).
A unique system MAC per chassis is used to break the activity tie in case that both nodes assume
the same activity state (for example, recovery after MCS isolation). The system MAC is
exchanged between multi-chassis peers through Multi-Chassis Synchronization (MCS)
protocol.
Diameter Proxy is configured on both 7750 SR nodes, through a Diameter policy that can now
be configured in a proxy mode. Diameter clients (Gx, NASREQ) on both 7750 SR nodes
connect to the Diameter Proxy via another Diameter policy that is in non-proxy mode. The
connectivity between the Diameter client and the Diameter Proxy is established through IPv4
even in the case where both entities (Diameter Client and Diameter Proxy) reside in the same
7750 SR node.
Diameter multi-chassis redundancy is supported for Gx and NASREQ. Within Gx, only ESM
is supported. See Enhancements in Release 13.0.R4 for more information.
DHCP Relay on Release 13.0.R1 adds support for DHCPv4 relay on network interfaces. Highlights of this
Network Ports feature are:
• support for Python-policy
− Python module alc.dhcpv4 is supported

New Features
− Python module alc.dtc is supported, except for alc.dtc.setEXM(), which is not

supported
• support for only DHCPv4 packets received natively via network interfaces
• no support for DHCPv4 packets over an MPLS tunnel
• no support for lease-populate
DHCP Relay Proxy Release 13.0.R1 introduces a DHCPv4 relay proxy function enhancing the DHCPv4 relay
functionality with a mechanism to hide the DHCPv4 server infrastructure details for DHCPv4
clients. A DHCPv4 relay proxy can act as a server towards the DHCPv4 client by replacing the
Server Identifier with a local IP address.
The existing functionality to relay unicast DHCPv4 request messages is merged in the new
relay-proxy function. The relay-unicast-msg CLI command is deprecated and during a
software upgrade, automatically migrated to the equivalent relay-proxy CLI command. See
Changed or Deprecated Commands for more information.
Relay proxy can be enabled on group-interfaces and on regular interfaces in IES and VPRN
services.
IPoE Session Release 13.0.R1 introduces the concept of an IPoE session enabling single authentication and
session accounting for dual stack devices. Mid-session changes are applied to the IPoE session.
An IPoE session is a logical grouping of IPoEv4 and IPoEv6 subscriber hosts that represent the
different IP stacks of the same end device and that share all authentication data, such as
subscriber ID, SLA profile instance, or session-timeout.The grouping is based on a configurable
session key per group-interface: {SAP, MAC address} by default and can be extended with
Circuit-ID/Interface-ID or Remote-ID for N:1 deployments.
An IPoE session represents a single end-device and can have following associated IP stacks:
• a single IPv4: one DHCPv4 host
• a maximum of two IPv6 WAN: one DHCPv6 IA-NA host and/or one SLAAC host
• a single IPv6 PD: DHCPv6 IA-PD host or PD as managed route (DHCPv6)
A single authentication is performed for all subscriber hosts in an IPoE session. Re-
authentication is based on a configurable minimum authentication interval and is triggered by a
renewal of any host belonging to the session.
With session accounting, a RADIUS accounting start is generated when the first host of the
session is created and accounting stops when the last host of the session is deleted. Optionally,
triggered interim update messages can be generated when a host is deleted from the session or
an additional host is connected.
IPv6 Support for Release 13.0.R1 adds IPv6 support for IPoE hosts/sessions and PPPoE sessions terminating in
Wholesale / Retail a retail subscriber interface in an IES or VPRN service.
L2TP LAC Multi- Multi-chassis stateful redundancy on BNG is now supported for L2TP LAC to protect access
chassis Stateful and network failures including the following functionalities:
Redundancy • MCS to synchronize L2TP tunnel/session information including sequence number of L2TP
control messages with associated PPPoE sessions

New Features
• SRRP-aware interface route to advertise L2TP endpoint address via routing protocols
based on SRRP mastership
Tunnel Selection Release 13.0.R1 enhances the tunnel selection capability on L2TP LAC:
Enhancements on • In previous releases, only one tunnel server endpoint was supported per tag in Access-
L2TP LAC Accept RADIUS message for L2TP LAC. Release 13.0.R1 introduces the support of
multiple endpoints with the same tag value.
• Release 13.0.R1 adds a new L2TP tunnel selection algorithm, “weighted-random”, which
enhances the existing weighted-access algorithm. When there are multiple tunnels with an
equal number of sessions (equal weight), LAC randomly selects a tunnel.
NAT Version negotiation (version 1 and version 2) for PCP is now supported.
Multicast: IPv4 PIM Release 13.0.R1 introduces the support for PIM on an IES subscriber group interface for SAP-
Support for level replication. On an IES subscriber-interface, an Ethernet SAP is configured (LAG or
SAP-level physical port) under the group interface. On the SAP, a static-host is configured for connectivity
Replication on IES to a downstream Layer-3 aggregation device including PIM while multiple default-hosts can be
Group Interface configured for subscriber traffic. A single SAP with a single static-host per group interface is
supported. Locally attached receivers cannot be mixed in the list of outgoing interfaces (OIF)
with the PIM OIF on a group interface. Default anti-spoofing must be configured (IP+MAC).
The feature requires FP2- or higher-based hardware.
Local DHCPv4/v6 Release 13.0.R1 introduces the following enhancements to local DHCP server:
Server • Local DHCPv6 server:
Enhancements
− sticky lease for DHCPv6 solicited release from client
− sticky lease for local IPsec client via local address assignment
− increase in the maximum configurable days for lease-hold-time to 7305
− assignment of /128 IA_NA address without reserving the corresponding /64 block if
there is no RESERVED_NA_LEN vendor sub-option in the relay-forward message
− ability to configure multiple thresholds on pool and prefix level based on a specified
prefix length. System sends out a warning if the configured threshold is exceeded.
With threshold configured, the system also collects statistics for the specified prefix
length.
− ability to configure one or more exclude-prefixes, which are excluded from available
prefixes in the pool
• Local DHCPv4 server:
− sticky lease when the lease expires (default)
− ability to optionally enable sticky lease for solicited release and local IPsec client via
local address assignment
− sticky lease support for persistency, HA, and MCS

New Features
− a configurable option to allow the system to send DHCP NAK when all of the
following conditions are satisfied:
− the local DHCPv4 server receives a DHCP Request with option 50
− the result of the address-allocation algorithm is using a pool scope
− the address in option 50 is not in the result pool
ESM BGPv6 ESM BGP IPv6 peering is now supported in addition to the currently available BGP IPv4
peering. The peering session is automatically set up as the subscriber IPv6 host is instantiated.
The BGP-peering policies contain a list of parameters for the BGP peering and is passed down
from RADIUS. Individual BGP attributes that are unique to each host can also be passed from
RADIUS. If the WAN address of the host is a peering address for the BNG, both SLAAC and
DHCPv6 IA-NA addresses are supported. The peering address for the client is any reachable
loopback address on the BNG.
ESM RIP Listener RIP listener is now supported for both PPP and IPoE IPv4 ESM hosts. RIP messages sent by a
host must either be multicasted or unicasted to the destination IP address. RIP messages sent
using the subnet broadcast will be dropped by the BNG. To enable RIP listener, the host requires
a RIP policy and the group interface to be added as a RIP neighbor. RIP policies can either be
passed from RADIUS or Local User Database (LUDB) during authentication. For static host,
the RIP policy can be associated directly to the host. RIP routes are only learned from hosts and
are never sent to hosts. SRRP setups are also supported. RIP routes are never synchronized via
MCS and require relearning after a failure. MCS will only synchronize the RIP policy.
SLA-profile An SLA profile can now offer a host-limit per host type and per address-family type. Prior to
Host-limit this release, host-limit can only limit the total number of hosts that share the same sla-profile
under the same subscriber. For example, it was not possible to provide a separate limit for PPP
hosts and DHCP hosts.
IPv6 Static Host IPv6 static hosts are now supported in addition to the currently available IPv4 static hosts. For
IP-only type of hosts, there are several MAC learning mechanisms: linking to IPv4 host,
learning via host’s router/neighbor solicit, and triggered SHCV. When the SAP is configured as
a single-MAC SAP, it changes the MAC learning behavior for the IPv6 static host only. It does
not apply to IPv4 static hosts. The single-MAC feature automatically populates the IPv6 host
MAC via host’s router solicits and neighbor discoveries.
UPnP IGD Support Release 13.0.R1 introduces the support of UPnP Internet Gateway Device (IGD) v1.0 which
allows clients to dynamically create port-mapping on MS-ISA/MS-ISA2 via UPnP protocol.
This feature only works with L2-Aware NAT and supports only required actions in
WANIPConnection service. This feature does not support distributed subscriber management.
WLAN-GW/WiFi: Release 13.0.R1 provides steering of traffic received on an access VLAN or spoke-SDP from a
VLAN to WLAN- WiFi AP/AC to a WLAN-GW IOM/IMM via an internal Epipe. The benefit of this internal
GW IOM/IMM steering is that all existing features available with native soft-GRE tunnels on WLAN-GW
Steering via IOM/IMM are now available to pure Layer-2 access via VLANs or spoke-SDPs. The access
Internal Epipe SAP can be null, dot1q, or QinQ. The aggregation network can insert up to two “AP identifying”

New Features
VLAN tags, and the AP can additionally insert a dot1q tag, typically for identifying the SSID.
The number of AP identifying tags sent on the internal Epipe depends on the encapsulation on
the access SAP (for example, if the aggregation network inserts two AP identifying tags, and
the access SAP is configured with null encaps, then the traffic sent on the internal Epipe will
carry two AP identifying tags). The traffic on an internal Epipe is load-balanced amongst MS-
ISAs in the WLAN-GW group. The load-balancing uses a hash based on AP-identifying tags
that remain on the frame after being received on the access SAP. This ensures all traffic from a
particular AP is Epiped to the same MS-ISA. Ingress/egress QoS and filters can be defined in
an epipe-sap-template and associated with the access SAP or spoke-SDP. Egress QoS is not
applied if a retail tag is present. Both Layer-3 ESM/DSM and Layer-2 wholesale are supported
for steered traffic. In Release 13.0.R1, mobility from an AP that is reached over a VLAN or
spoke-SDP to an AP that is reached over soft-GRE or soft-L2TPv3 tunnels is not supported. See
Enhancements in Release 13.0.R2 for more information.
WLAN-GW/WiFi: Release 13.0.R1 adds the support for soft-L2TPv3 tunnels. L2TPv3 is over UDP and both IPv4
Soft-L2TPv3 and IPv6 transport is supported. The encapsulation with UDP allows NAT traversal. Soft-
Tunnel Support L2TPv3 tunnels are terminated on WLAN-GW IOM/IMM. All features supported with soft-
GRE tunnels are supported identically with soft-L2TPv3 tunnels. L2TPv3 tunnels are stateless,
and there is no support for control channel, dynamic exchange of session ID and cookie, and
L2-specific sub-layer for sequencing. A cookie received in L2TPv3 is reflected back. The AP
can encode its MAC address in an eight-byte cookie. Based on the configuration, the cookie can
be parsed to interpret AP-MAC from the least significant six (6) bytes. The mobilty between
APs reachable via soft-L2TPv3 tunnels and APs reachable via soft-GRE tunnels is supported.
There is feature and scale parity between soft-GRE and soft-L2TPv3 tunnels.
WLAN-GW/WiFi: Release 13.0.R1 adds the support for WLAN-GW features on MS-ISM. MS-ISM provides both
WLAN-GW on higher throughput and session scale compared to an IOM with MS-ISAs. There is feature parity
MS-ISM (Two for WLAN-GW between an IOM with MS-ISAs and an MS-ISM. The MS-ISA2s can be
MS-ISA2s) configured with an isa-bb image or an isa2-bb image. If it is configured with an isa-bb image,
then the session scale of an MS-ISA applies, but the higher throughput of an MS-ISA2 is
provided. This allows mixing of MS-ISAs and MS-ISA2s in the same WLAN-GW group.
WLAN-GW/WiFi: Release 13.0.R1 adds the support for mapping a UE to a VPLS instance based on configuration.
L2-Wholesale The mapping is explicitly created by assigning a Layer-2 (L2) service instance (VPLS only in
Support Release 13.0.R1) to an SSID to which the UE is connected. The SSID is represented by the
dot1q tag in the received L2 frames from the UE. A VPLS instance can be configured per VLAN
range on a WLAN-GW group-interface. This feature therefore enables L2 wholesale, where
traffic from all UEs on a particular SSID is transparently forwarded into the corresponding
VPLS instance associated with the retail ISP. UE authentication, address assignment, Layer-3
(L3) classification and QoS are managed by the retail provider terminating the subscriber. The
WLAN-GW applies split-horizon to prevent local-switching between UEs. L2 wholesale and
L3 termination are possible simultaneously on the same WLAN-GW interface, since L2
wholesale or L3 termination is a per-SSID decision. The UE MAC state in the L2-FDB on the
IOM ages out based on the local-age configured under the VPLS service. The UE state on the
MS-ISA/MS-ISA2 is removed via an idle timeout and re-established via normal MAC learning.
IP filters and QoS can be specified in a VPLS-SAP template associated with the VPLS service.

New Features
The UE MAC scale is limited by the number of MAC entries supported in the IOM-based L2-
FIB. The number of unique VPLS instances is limited by the maximum number of supported
VLAN ranges.
Application The following section describes the new Application Assurance features in Release 13.0.R1.
Assurance
SeGW AA Firewall ISA-AA Firewall protection feature in Security Gateway (SeGW) deployment is enhanced in
Enhancements Release 13.0.R1 to provide S1-U GTP and S1-MME traffic protection. ISA-AA in Release
13.0.R1 implements added functionality to support: SCTP chunk checking, SCTP PPID
filtering, GTP-U tunnels count and rate limiting, GTP packet sanity check – invalid reserve,
invalid reserved IE, Missing IEs, GTP message type filtering, and GTP length filtering.
Local-List URL Local-list URL filtering policy allows network operators to deploy a solution preventing access
Filtering to illegal content in the context of child protection, court order URL takedown or driven by
specific country regulations.
The list of URLs is stored locally in a file located on the system compact flash providing a cost
effective solution for this type of filtering. The list can be updated automatically and the system
supports both encrypted and non-encrypted files.
SRRP Interface In the context of an ESM SRRP deployment, the operator can define at the app-profile level if
and Suppressible the subscriber will be diverted to MS-ISA/MS-ISA2 on a per-SRRP group interface basis. This
App-Profile can be used to reduce the total number of MS-ISAs/MS-ISA2s required in the event of a High-
Availability switchover from a primary to backup SRRP node when Application Assurance is
used as a value-added service for selected subscribers.
DNS IP Cache Release 13.0.R1 introduces the dns-ip-cache feature for URL content charging strengthening.
Subscribers’ DNS responses matching a list of domain names used for content charging are used
to populate the dns-ip-cache. The system can then be configured to create app-filters matching
HTTP or HTTPS expressions as well as the IP cache, ensuring that traffic is properly classified.
OAM The following section describes the new OAM features in Release 13.0.R1.
ETH-CFM MIP Classic MIP support has been added to mesh-SDP bindings.
Support on MESH-
SDP Bindings
IP Performance Support has been added to allow for the recording of loss and availability metrics under the
Monitoring OAM-PM architecture. The operator must specifically select the appropriate record-stats
(TWAMP-Light) option to record the desired metric. By default, only delay statistics are collected. To change this
recording option an active test must be shutdown and the appropriate configuration modified,

New Features
then activated with the no shutdown command. It is important to remember that no shutdown
will reallocate the system memory for that test. Any statistics not collected or written to compact
flash will be lost when the memory is reallocated.
Ipipe CFM Fault Ipipe Ethernet to legacy (encap-type PPP, MLPPP and Cisco-HDLC) interworking has been
Propagation to enhanced to allow faults on the Ethernet SAP to be propagated to the legacy connection.
Legacy Activation of the Ethernet to legacy fault propagation requires the eth-legacy-fault-
notification command to be included with the Ipipe service configuration. When using
ce-address-discovery the new keep option, only available when eth-legacy-fault-notification
is enabled, must be used to ensure that the learned address on the Ethernet SAP is not flushed
when the SAP enters a non-operational state.
LLDP Port-Id- LLDP now includes the ability to select the port-id-subtype that will be carried in the port-id
Subtype field. The default remains ifIndex. The ifIndex value is required by some versions of Alcatel-
Lucent 5620 SAM to properly build the Layer-2 topology map using LLDP. Changing this
value to transmit the ifName or ifAlias in place of the ifIndex may affect SAM’s ability to build
the a Layer-2 topology map using LLDP.
LLDP System Management Address now includes support for both IPv4 (Address SubType 1)
and IPv6 (Address Subtype 2).
EFM Link Support has been added for link monitoring of frame errors and symbol errors. Symbol errors
Monitoring require specific hardware versions; contact your Alcatel-Lucent representative for the current
hardware list. Signal degrade, signal failure and the various windowing capabilities have been
included in this support. The operator can configure actions based on signal failure threshold
crossing and a number of peer notification and reception actions.
OAM-PM Event Threshold Crossing Alarms (TCA) can be configured against the various key performance
Monitoring metrics collected as part of the OAM-PM architecture. Both stateful and stateless TCA are
supported for delay, loss and availability metrics.
VXLAN Ping A new VXLAN troubleshooting tool vxlan-ping is available to verify VXLAN VTEP
connectivity. The vxlan-ping command is available from interactive CLI and SNMP.
Y.1731 ETH-LMM ETH-LMM support has been extended to UP Service MEPs and Facility MEPs (port, LAG, and
Enhancements base-router interfaces). Service MEPs and Facility MEPs are not supported over the same
resource. The operator must choose a Facility-MEP approach or a Service-MEP approach when
the underlying resource is shared. If Facility MEPs are chosen to collect the frame loss statistics
then only a single Facility MEP on that resource can collect the frame counters. If more than
one facility MEP is configured on the shared resource, then highest-level MEP must be
configured to collect frame loss statistics to avoid the artificial introduction of gain.

Enhancements
Enhancements
The following sections describe new enhancements in SR OS releases.
Note:
• For the list of new and updated Application Assurance protocols and applications
supported in Release 13.0.R10 and previous 13.0 releases, see the following spreadsheet
at the Alcatel-Lucent online customer support site:
SR OS 13.0 AA Protocols and Applications
The spreadsheet may also be updated between maintenance releases to reflect recent AA
protocol and application updates. To subscribe to document and spreadsheet notifica-
tions, see the online customer support site.
For a complete list of all AA protocols and applications, contact your regional support
organization.
Release 13.0.R10
Hardware • The 7750 SR-1e/2e/3e now supports the show system switch-fabric command. [215958]
• Release 13.0.R10 reduces the automatic recovery period to less than a second for a rare
condition on an FP3-based forwarding plane that may have resulted in traffic being
impacted for a few seconds. [224433]
OSPF • The OSPF routing feature set is extended so that the lsa-generate timer now governs LSA
generation for self-generated LSAs with MaxAge. Prior to Release 13.0.R10, there was a
rare condition that caused the LSA to be flooded immediately if the router received an LSA
with its own router ID because a duplicate ID had been configured in the network.
[228017]
Routing • The output of the show router interface ipv6 detail and show service id interface ipv6
detail commands now displays ICMPv6 values. [210216]
Release 13.0.R9
HW/Platform • The operational state (for example, tmnxHwOperState in SNMP) of the extension chassis
in a 7950 XRS-40 system and the operational states of equipment contained in the
extension chassis (for example, CCMs) have been changed in CLI and SNMP to return a
value of “pre-extension” when the system is in 7950 XRS-20 mode (chassis topology =
standalone). [190843]
• The CPMs on the nodes can now use the BITS input port from their mate CPM along with
the previously-supported local BITS input port. On 7950 XRS-16c/20 and the Master

Enhancements
chassis of the 7950 XRS-40, the CPMs can use the BITS input ports on CPM/CCM A and
B. On the extension chassis of the 7950 XRS-40, the CPMs can use the BITS input ports on
CCM C and CCM D. [213779]
BGP • Release 13.0.R9 aligns VPRN BGP out-of-memory handling with the main BGP instance
mechanisms. In prior releases, the entire VPRN instance was always shut down if BGP
running in the VPRN was unable to obtain memory to store new routes. Now, if the new
route comes from a VPRN BGP peer, only that peer is shut down. [227877, 230151]
MSDP • The multicast routing feature set is extended with MSDP routing in a VPRN for Rosen
MVPN and NG-MPVN. [188490]
NAT • SIP Application Layer Gateway (ALG) signaling sessions support up to eight (8) pinholes.
Prior to Release 13.0.R9, after the eight (8) pinholes per SIP session had been allocated, the
new request for additional pinholes would have been rejected.
Starting with Release 13.0.R9, the new requests for pinholes will be honored by deleting
the oldest pinholes in order to accommodate the new ones. The total number of pinholes
per SIP session remains at 8. [227554]
Release 13.0.R8
HW/Platform • Release 13.0.R8 introduces new, optional firmware for p20-1gb-sfp in imm-2pac-fp3 that
adds the support for IEEE 1588 Port-Based Timestamping as well as extra pre-
classification based on IPv6 DSCP markings and some EtherTypes. [199381]
• Release 13.0.R8 adds the reset-on-recoverable-error configuration option in the
config>card context on the 7750 SR-7/12/12e and 7450 ESS-7/12 platforms. When this
option is enabled, and there is a recoverable error in the forwarding path, but that recovery
action can have a traffic forwarding impact of a few seconds, the card will reset instead of
taking the recovery action. [218111]
MPLS • Release 13.0.R8 allows the configuration of a metric for a static LSP. By default, a static
LSP is assigned the maximum metric value of 16777215. [212659]
WLAN-GW • Release 13.0.R8 provides the support for seamlessly updating a UE when it moves from
one AP to another and a control packet is received from the UE with a dot1q tag that is
different than the one that the UE is currently associated with. [222804]

Enhancements
Release 13.0.R7
HW/Platform • Release 13.0.R7 adds the reset-on-recoverable-error configuration option for the
7950 XRS in the configure card x mda t context. When this option is enabled and there is
a recoverable error in the forwarding path with that recovery action having some traffic
forwarding impact, the XMA/C-XMA will reset immediately instead of taking the
recovery action. [213869]
NTP • The default behavior for event notification for the tmnxNtpServerChange event of the NTP
application has been changed to suppress. [218342]
Cflowd • Release 13.0.R7 introduces the new mpls-transport template-set option for Cflowd v9
and v10 collectors. This new option allows Cflowd to collect flow statistics for MPLS
traffic using only the outer transport label, EXP bit value and ingress interface as the flow
identifier. The intent of this new template is to allow the collection of flow statistics on a
core router to develop LSP usage metrics. This option is enabled by configuring one or
more v9 or v10 collectors to use the mpls-transport template for collected statistics.
Different Cflowd collectors should not be configured to use both mpls-transport and
mpls-ip templates concurrently. Doing so would result in MPLS traffic having to be pro-
cessed twice and would significantly reduce Cflowd processing rates.
This new template is configured through the following template-set command:
config>cflowd>collector>template-set {basic | mpls-ip | l2-ip | mpls-transport}
[183594]
LAG • Mixed-Speed LAG with ESM is now available for the production network. This feature
was introduced in Release 13.0.R4.
LDP • Release 13.0.R7 introduces a new global LDP configuration option legacy-ipv4-lsr-
interop to allow interoperability with third-party legacy IPv4 LSR implementations that do
not comply with RFC 5036 with respect to the processing of Hello TLVs with the U-bit set.
Configuration of this command disables the following Hello TLVs:
− Alcatel-Lucent proprietary Interface Info TLV (0x3E05) in the Hello message sent to
the peer. Disabling this Hello TLV also results in the non-generation of the Alcatel-
Lucent proprietary Hello Adjacency Status TLV (0x3E06) because the Interface Info
TLV is not sent. [214697, 218464]
− The RFC 7552 standard dual-stack capability TLV (0x701) and the Alcatel-Lucent
proprietary Adjacency capability TLV (0x3E07) in SR OS Release 13.0 and higher
releases. [217080]
IPsec • In non-resilient topologies, IPsec tunnels are no longer deleted on the master chassis when
the Multi-chassis IPsec Mastership Protocol (MIMP) session to the standby chassis is re-
established while the MS-ISAs/MS-ISA2s are rebooting on the standby chassis. [208268]

Enhancements
NAT • The SIP timeout value in NAT is now increased to two (2) hours. [219616, 220146]
Application • url-filter policy action for ICAP and local-filtering now uses the TLS Certificate
Assurance Common Name expression in case the Server Name Indication is not present. Prior to
Release 13.0.R7, url-filter policy would not filter TLS sessions in case the Server Name
Indication was not present. [208082]
WLAN-GW • SR OS now supports seamless “DHCP triggered” mobility. If DHCP DISCOVER or

REQUEST is seen on a different tunnel than what the current UE state points to, based on
configuration, the ESM host corresponding to the UE is seamlessly updated. [219748]
Scaling The scaling numbers have increased for the following areas. Contact your Alcatel-Lucent
representative for details:
• Subscriber Management: ESM-based dynamic BGP peers per system [215614]
Release 13.0.R6
HW/Platform • On the 7950 XRS, when there had been a fail-on-error condition due to a low-level event
on an XMA or C-XMA, the XCM itself was taken out of operation. An XMA or C-XMA
sharing the same XCM would also have become operationally down. Starting with Release
13.0.R6, fail-on-error for any low-level event on the XMA or C-XMA will be limited to
only that XMA or C-XMA instead of the whole XCM being taken out of operation.
Important notes:
− to enable this new behavior, fail-on-error must be configured in the
config>card>mda context
− the fail-on-error function will no longer be active on the 7950 XRS if it is only
configured in the config>card context [199185]
• Release 13.0.R6 introduces a user-configurable enhancement to down-on-internal-error
that allows the user to turn-off the laser on the impacted port. In some scenarios, this speeds
up redundant path switchover, especially when higher-layer OAM functions are not used or
enabled. The behavior to re-enable the laser and clear the error condition has not been
changed, which still requires that the port be toggled operationally (shutdown/no
shutdown). [205316]
• SR OS includes the display of the virtual machine UUID to the output of show system
license on virtualized systems. The virtual machine UUID is also included in the output of
the show card slot number {[1..10] | A | B} detail command. [209653]
System • The configurable, alternative prioritization scheme that has been introduced for extracted
control plane traffic is now available for the production network. This enhancement was
introduced in Release 13.0.R5.

Enhancements
DHCP • Release 13.0.R6 introduces a new format for circuit-id/remote-id of DHCPv4 snooping on
a VPLS SAP. This new format allows the user to configure a hexadecimal string as the
value of the circuit-id/remote-id. [193399]
IS-IS • The output of the show router isis command has been extended to show the instance name
in the headers. [207574]
• For the IS-IS implementation of the IGP shortcuts feature, as described in RFC 3906, when
IS-IS performs an IP-reachability computation following that of the SPF tree, nodes and
prefixes downstream of a tunnel endpoint node will now inherit only the direct tunnels used
to reach the endpoint node when the latter is a parent node.
Prior to Release 13.0.R6, while IS-IS used only the direct tunnels to reach the endpoint
node and prefixes owned by the endpoint node, it computed all possible ECMP paths to
reach prefixes and nodes downstream of a tunnel endpoint. These ECMP paths included
those using direct tunnels terminating on the endpoint node, tunnels terminating prior to it,
and IP next-hops up to the router ecmp value. [211050]
BGP • General Support for Dynamic BGP Sessions is now supported for the production
environment. This feature was introduced in Release 13.0.R5.
MPLS • Release 13.0.R6 introduces the ability to configure the TTL of GMPLS UNI IPCC packets
(RSVP and LMP). This allows the use of a Layer-3 data communication network with
more than one hop between an SR OS router and an adjacent UNI-N node. [214242]
IP Multicast • The multicast ECMP hashing feature configured with mc-ecmp-hashing-enabled is

enhanced with the rebalance option. When this option is enabled, the router rebalances
flows to newly added links immediately instead of waiting until they are pruned. [150739]
• The multicast routing features for IGMP, MLD, PIM, and MSDP, are extended to accept a
source-address prefix-list-name instead of a single IP address. Using a prefix-list instead
of multiple policy statements simplifies and reduces the number of routing policies.
[166117, 211839]
QoS • Prefix lists for QoS policies applied to the ingress and egress of an SLA profile can now be
used in the production network. This feature was introduced in Release 13.0.R4.
Services • EVPN multi-homing is now available for the production network. This feature was
introduced in Release 13.0.R4.
• PBB-EVPN multi-homing in I-VPLS and Epipe services is now available for the
production network. This feature was introduced in Release 13.0.R4.
IPsec • An optional IPsec-gateway name parameter has been added to the show ipsec gateway
tunnel private-address-type private-address-type command: show ipsec gateway name
name tunnel private-address-type private-address-type. This updated command provides
an output that shows the IPsec tunnels with a specified type of private address that
terminate on a specified IPsec-gateway. [213563]

Enhancements
Mirroring/Lawful • Routable Lawful Intercept encapsulation (config>mirror>mirror-dest>encap>layer-3-

Intercept encap) is now supported for IPv4 destinations reachable over a spoke interface using a
LDP IPv6 FEC.
• Segment-routing tunnels over IS-IS and OSPF can now be used for remote mirroring.
[214550]
L2TP • Release 13.0.R6 adds the support for sending AVPs for L2TP tunnels in ESM session
accounting. It also allows to send Acct-Tunnel-Connection value in a different format
including local tunnel-ID, local session-ID, remote tunnel-ID, remote session-ID, and
Calling-Number. [208200]
NAT • The NAT-related logger event 2021 is changed so that each 2012 “map” event is matched
with a 2021 “free” event, rather than sending a summarization 2021 log for the last port
block of the subscriber which does not contain the last freed port-block. [196154]
• The outside IP and port allocation algorithm has been enhanced for L2-Aware NAT. Prior
to this change, a just-released outside IP and port for a subscriber that was being deleted
could have been immediately reallocated to a new subscriber. Corresponding RADIUS
logging could have resulted in an Accounting-Stop and Accounting-Start within the same
second, reporting the same outside IP and port for different subscribers. External systems
could have wrongly interpreted this as an outside IP and port overlap condition. [217088]
sFlow • In Release 13.0.R6, sFlow has been enhanced to support the 7750 SR-7/12 systems with
CPM3/CPM4/CPM5 on multi-core line cards. [201089]
Application • The 13.0 AA Protocols and Applications for the 7450 ESS and 7750 SR spreadsheet has
Assurance been added to the SR documentation suite. This spreadsheet may be updated between SR
maintenance releases to reflect recent AA protocol and application updates. A link to the
document is also provided at the beginning of the Enhancements section.
OAM • Log and debug messages relating to G.8032 Ethernet Ring Protection Switching have been
modified to reference paths a/b instead of paths 0/1. [213859]
• Release 13.0.R6 introduces the support for VCCV BFD on the 7450 ESS-6/6v. [214672]
• sFlow can now be configured on an increased number of SAPs per port. [201089]
• The number of DHCPv6 (IA-NA, IA-PD) lease-states per regular IES or VPRN interface
(non-subscriber interfaces) with lease-populate enabled. [205939]

Enhancements
Release 13.0.R5
RADIUS • Authentication Requests are no longer forwarded to a RADIUS server that is in state
“overload” because the “pending-requests-limit” value is exceeded. [212937]
System • A configurable, alternative prioritization scheme has been introduced for extracted control-
plane traffic. The new scheme can be enabled (on a per-FP basis with the CLI init-extract-
prio-mode command) to initialize the drop priority of extracted Layer-3 control traffic
based on the QoS classification of the packets. This is useful in networks where the DSCP
and EXP markings can be trusted as the primary method to distinguish, protect, and isolate
“good” terminating protocol traffic from unknown or potentially harmful protocol traffic,
instead of using the rate-based distributed CPU protection (DCP) and centralized CPU
protection traffic marking/coloring mechanisms (such as out-profile-rate and exceed-
action low-priority). See Enhancements in Release 13.0.R6 for more information.
• Support for APEQ provisioning has been added to the 7750 SR-12e platform to allow
management of the APEQ input power mode through the addition of the following
commands:
− show peq
− configure system power-management peq
− show chassis power-management [206787]
Routing • OSPF with segment routing and multiple areas for the ABR role is now available for
production networks. This feature was introduced in Release 13.0.R4.
• The ICMP/ICMPv6 packet processing rate on transit packets that generate an exception
condition has been increased on 7450 ESS-7/12 and 7750 SR-7/12/12e platforms with
Multicore-CPU and FP3-based IMMs/IOMs, and on 7950 XRS platforms. [207965]
OSPF • Release 13.0.R5 introduces the tools dump router router ospf instance area-range
command, which shows the dynamic parameters and the aggregated routes of an OSPF
area-range. [212766]
MPLS • Release 13.0.R5 adds the support for a new tools dump test-oam command on the tail-end
of an LSP to display statistics related to LSP BFD. A new MIB object is also added that
shows ongoing LSP BFD bootstrap retry counts. [211899]
Application • Release 13.0.R5 supports a new version of the isa-aa.tim file that enables new and updated
Assurance protocol signatures and applications. The new and updated protocols in this release are

Enhancements
shown in the table below. For a complete list of the Release 13.0 AA identification
capabilities (protocols and applications), contact your regional support organization.
Table 17. New and Updated AA Protocols in Release 13.0.R5

Protocol Status Comments
DNS Tunnel new Provides detection of DNS Tunneling. DNS tun-
neling can be used to bypass WiFi captive portal
access restrictions and allow subscriber access to
Internet. It can also be used to bypass content
charging rules.
Speedtest new Provides detection of the Speedtest.net Internet
access analysis service.
Bittorrent updated Provides improved detection of Bittorrent traffic
over Teredo.
eMule updated Provides improved detection of eMule over UDP
when connected to the Kad network.
Google Talk updated Provides improved detection of Google Talk when
initiated with TCP Fast Open.
LINE updated Provides improved detection of LINE voice and
video calls over UDP.
Lync updated Provides improved detection of Microsoft Lync
over TCP.
Skype updated Provides improved detection of obfuscated Skype
over UDP.
TLS_HTTP2 updated Provides improved detection of TLS_HTTP2 when
initiated with TCP Fast Open. These flows were
previously detected at TLS.
WhatsApp updated Provides improved detection of WhatsApp traffic
over TCP.
YouTube updated Provides improved detection of YouTube live event
streaming over RTMP.
• Release 13.0.R5 includes TCP Fast Open support for DPI high-touch features such as
HTTP-Enrichment, In-Browser Notification, HTTP-Redirect, URL-Filter, URL-List and
Match-all. TCP Fast Open is an extension to TCP used to speed up the opening of
successive sessions between a client and server by sending data during the initial three-way
TCP handshake.
Release 13.0.R4
Hardware • 10 GBase tunable DWDM SFP+ (low-power 1.5 watts MSA-compliant) is now supported
on the SFP+ based cards. [200880]
• Release 13.0.R4 introduces a new firmware for the control path on 7750 SR-a4 and SR-a8
which unlocks scaling and performance improvements at the control-plane layer. The

Enhancements
firmware upgrade will take place automatically on the first attempt to boot Release
13.0.R4. Note that the firmware upgrade process will take longer than a simple software
upgrade so maintenance window plans may need to be adjusted accordingly. Also note that
care must be taken to avoid any resets or removal/insertion of any assemblies in the system
while the upgrade is taking place or cards may be rendered inoperable.
• In Release 13.0.R4, both ingress and egress XPL error trap counts will be displayed under
show mda detail. [210513]
System • A new configuration item under the config>system>security>source-address hierarchy is

available to allow an operator to specify the source IP address to be used for ICMP and
ICMPv6 error messages sourced from the node. This is supported in the base routing
instance and in VPRN services (under the config>service>vprn>source-address context).
If this item is not configured, the default behavior is that the node will source
ICMP/ICMPv6 error messages from the interface on which the packet that triggered the
message was received. [143038]
• Release 13.0.R4 enhances the load balancing hash algorithm configured with system-ip-
load-balance to also work with pure Layer-2 traffic. Previous releases use this algorithm
for Layer-3 traffic only. [179818]
• The per-SNMP community source IP address validation feature has been enhanced to
operate with VPRN SNMP communities and USM communities. As of Release 13.0.R4, a
src-access-list can be referenced by a VPRN SNMP community or an SNMP USM
community. [204677]
• A new min-delay parameter has been added to the Event Handling System to prevent a
script from running too often.
Hybrid OpenFlow • Release 13.0.R4 introduces interface support enhancements. OpenFlow (OF) is enabled on
Switch (H-OFS) an interface by assigning an IPv4 and/or IPv6 line card filter policy with H-OFS instances
embedded in that policy either directly or via the active system filter policy. The following
new CLI contexts, in addition to those listed for Release 13.0.R1, support an assignment of
IPv4 and/or IPv6 line card filter policies with embedded H-OFS instances:
− access interfaces:
− config>service>ies>if>spoke-sdp>ingress>filter
− network interfaces:
− config>service>vpls>mesh-sdp>ingress>filter (requires H-OFS with switch-
defined-cookie enabled)
− config>service>vpls>spoke-sdp>ingress>filter (requires H-OFS with switch-
defined-cookie enabled)
• Release 13.0.R4 introduces an enhanced statistics processing for an SR OS H-OFS. The
processing allows faster flow table statistics retrieval due to the use of the new CPM-based
ACL statistics cache. An OF controller statistics request that is translated to a bulk request
returns the CPM-cached values. An OF controller statistics request that is translated to a
single flow request returns values read real-time from hardware. The ACL CPM cache is
being refreshed in a background using a non-configurable refresh interval. On a High-
Availability switchover, a CPM cache needs to be rebuilt; as such, some initial bulk
requests may require another hardware read to return the statistics and repopulate the
cache. Note that prior to Release 13.0.R4, the returned statistics values were always read

Enhancements
real-time from hardware, which could have led to a degraded performance at very large OF
switch scale.
• Release 13.0.R4 adds the ability to program *.NULL and *.*VLAN ID match and
forwarding to VPLS SAPs using the Hybrid OpenFlow Switch (H-OFS). [199457]
• Release 13.0.R4 adds the ability to program a new PBR action forward next-hop ip-
address router router-instance using the OpenFlow protocol (see the Filters: PBR
enhancement in Release 13.0.R4 Enhancements for more information).
NETCONF/YANG • A new revisions.txt file is included in the YANG subdirectory of the SR OS image
distribution to indicate the revision of each Alcatel-Lucent YANG module associated with
the release. [207707]
• An unknown XML namespace or prefix declaration is now ignored in NETCONF requests
instead of generating an error. [209637]
Routing • In Release 13.0.R4, the cpe-check option for static routes is expanded to support an IPv6
target. This option initiates a background IPv6 ping to test the reachability to the associated
IPv6 target. The operational state of the static route will be brought down if the IPv6 ping
fails to the configured target. If the cpe-check option is configured for a static route, the
administrator can also specify a padding-size value up to 16384 bytes. [140022]
• In Release 13.0.R4, the IP interface command delayed-enable functionality has been
extended to the following IP interface types.
− config>router>interface
− config>service>ies>interface
− config>service>ies>redundant-interface
− config>service>ies>subscriber-interface
− config>service>vprn>interface
− config>service>vprn>redundant-interface
− config>service>vprn>network-interface
− config>service>vprn>subscriber-interface
− config>service>vpls>interface
The delayed-enabled function is also supported in association with VPRN and IES IP Tun-
nel, GMPLS loopbacks and Unnumbered MPLS-TP interfaces.
This option allows for a configurable timer which delays the enabling of the associated IP
interface by the specified amount of time. The configurable range is 1-1200 seconds.
[191826]
• Release 13.0.R4 adds a new set of optional parameters to the static-route configuration to
allow an exponential back-off behavior for static routes that are flapping. If configured, a
route that transitions from up to down and then up again before the current back-off
interval has expired would be held down (operationally down) for increasing periods, up to
the maximum hold-down value. This behavior will mitigate the effects of an unstable static
route that is flapping due to either traffic or link instability. [193468]

Enhancements
DHCP • Logging for DHCP errors has been enhanced. A DHCP server that failed to assign an
address to the subscriber host will log the host's MAC or DUID. A trap will also be sent if
a DHCP offer/advertise expires. [198158]
• A DHCPv4 Python script configured in a group-interface DHCPv4 context will now also
act on DHCPv4 release messages originated by ESM on behalf of a DHCP client attached
via that group-interface. [203170]
IS-IS • Release 13.0.R4 adds a new IS-IS option (config>router>isis>ignore-narrow-metric) to

force IS-IS to ignore links with narrow metrics when wide-metrics support has been
enabled. [163873]
• Release 13.0.R4 adds the support for IS-IS purge originator identification (POI) as
described in RFC 6232 and RFC 6233. A POI TLV, which contains the system ID of the
router that generated the purge, is added to purges. This addition simplifies
troubleshooting, and determining what caused the purge. [165786]
• The IS-IS Single Instance Router in a Non-Zero Instance feature is now available for the
production network. This feature was introduced in Release 13.0.R1.
OSPF • The show router ospf and show router ospf3 commands are extended with an all option
to show all configured OSPF instances. The command output is also extended to show the
instance ID in CLI output headers. [182039]
• The OSPF routing feature set is extended to limit the maximum number of LSAs that OSPF
can learn from another router in order to protect the system from a router that accidentally
advertises a large number of prefixes. When the number of advertised LSAs reaches the
configured percentage of the limit set with rtr-adv-lsa-limit, an SNMP trap is sent. If the
limit is exceeded, OSPF goes into overload. The overload-timeout option allows the
administrator to control how long OSPF is in overload as a result of the LSA limit being
reached. At the end of this duration of time, the system automatically attempts to restart
OSPF, or can be configured to stay in overload until cleared by the administrator.
This feature should be used together with the OSPF export-limit, which will limit the num-
ber of prefixes that can be exported from other protocols into OSPF. [182659]
BGP • Release 13.0.R4 changes the BGP implementation to handle unresolved routes more
consistently. Previously, for some address families, an unresolved “best” route was not
withdrawn when next-hop-self was in effect. Now, it will always be withdrawn under these
circumstances, regardless of the address family (IPv4, IPv6, label-IPv4, label-IPv6, VPN-
IPv4, VPN-IPv6). [172163]
• Release 13.0.R4 adds the ability to configure VPRN to be part of a BGP confederation to
import and export IP-VPN routes with confederation information included in their AS path
attributes. [186635]
BGP-EVPN • The EVPN-VXLAN BGP encoding in Release 13.0.R4 is now compliant with draft-ietf-
bess-evpn-overlay. Prior to Release 13.0.R4, the VXLAN Network Identifier (VNI) was
encoded in the Ethernet Tag field of the EVPN routes type 2, 3 and 5 following an early
version of the draft. In Release 13.0.R4, the VNI is now encoded in the Label field of the
EVPN routes as per the current draft. The sending and receiving behavior is described
below.

Enhancements
− When sending EVPN-VXLAN routes:

− the Ethernet Tag will now be zero (0)
− the VNI value will be encoded in the 24-bit Label field of the EVPN routes (this
field is called “Label1” in MAC/IP routes)
− When receiving EVPN-VXLAN routes, that is, EVPN routes with VXLAN value in
the RFC 5512 BGP tunnel encapsulation extended community, the VNI is extracted
based on the following rules.
− If the Label field and Ethernet Tag are both zero (0), the VNI selected to send
VXLAN packets will be the locally configured VNI value.
− If the Label field is non-zero and the Ethernet Tag is zero, the VNI will be equal
to the 24-bit value encoded in the Label field.
− If the Label field is zero and Ethernet Tag is non-zero, the VNI will be equal to
the value in the Ethernet Tag.
− If the Label and Ethernet Tag fields are both non-zero, the VNI will be equal to
the 24-bit value in the Label field. [201082]
• A new CLI command has been added so that the user can configure the EVPN
encapsulation for EVPN routes (MAC/IP, Inclusive Multicast Ethernet Tag, IP-prefix
routes and AD per-EVI routes) received without an RFC 5512 BGP tunnel encapsulation
extended community. Based on the configured value in
config>router>bgp>neighbor#def-recv-evpn-encap [mpls|vxlan], BGP will treat the
received EVPN routes without an encapsulation as either mpls or vxlan. The default value
is mpls.
BGP VPWS • The configuration of a GRE tunnel using static MPLS labels is now supported within a
single-homed BGP VPWS service; however, BGP multi-homing using an active and a
standby pseudowire to a pair of remote PEs is not supported. [203685]
MPLS/RSVP • The GMPLS UNI feature was released in Release 13.0.R1 for laboratory environments
only. This feature is now available for the production network.
LDP • In Release 13.0.R4, it is no longer possible for an MPLS label control protocol
(RSVP/LDP/BGP) to be affected when another MPLS label control protocol has MPLS
label resource issues on the IOM/IMM/XCM. [190080]
LDP IPv6 • The following LDP capabilities are now supported with LDP IPv6:
− overriding address advertisement using an address export policy when the LSR peer
did not advertise the dual-stack capability TLV
− LDP Downstream on Demand (DoD) label distribution
− LDP IPv6 session overload capability
− aggregate-prefix-match option
− FRR protection for a LDP IPv6 FEC
− mcast-upstream-frr option
− LDP IPv6 peer authentication using MD5

Enhancements
− LDP IPv6 prefix FEC limit

− LDP IPv6 Hello reduction
− LDP graceful restart helper
PIM • For IPv6 PIM SSM/ASM in C-instance, the receiver-PE threshold for S-PMSI trigger
feature, introduced in Release 13.0.R1, is now available for the production network.
• IPv6 MCAC for PIM and MLD is now available for the production network. This feature
was introduced in Release 13.0.R1.
QoS • A set of show commands have been added to display the QoS information relating to
aggregate rate-limit configurations (show qos agg-rate). [180781]
Filters • Release 13.0.R4 allows the operator to specify a direct/indirect next-hop IPv4/IPv6 address
and a target VRF instance for a PBR action in an IPv4/IPv6 filter policy. Prior to Release
13.0.R4, only a next-hop or a target VRF could be configured in the filter policy, although
next-hop and target VRF could be used for PBR using redirect policies. The new action is
supported in IPv4 and IPv6 filters.
• Release 13.0.R1 introduced the support for IPv4 and IPv6 filter policies on network ports
for VPRN services. In Release 13.0.R4, the filter functionality is available with the newly-
introduced per-prefix VPRN service label mode feature.
Services General • Release 13.0.R4 adds the ability to link a PW port state to the state of an oper-group, such
that if the oper-group goes down, the SDP binding for the PW port will also go
operationally down. [187673]
• In Release 13.0.R4, a new SDP option has been added which disables the setting of the do-
not-fragment bit in the IP header of GRE encapsulated service traffic.This feature is only
applicable to GRE SDPs and will be applied to all service traffic using the associated GRE
SDP. This option is enabled through the CLI command config>service>sdp>allow-
fragmentation. This option is not enabled by default. This option should only be enabled if
an external device is capable of re-assembiling the fragmented GRE traffic before it is
delivered to the far-end service router. [201894]
• In case of a MAC-move rate exceeded event in an I-VPLS service, the alarm message will
display only the B-VPLS service-ID. With this enhancement, the I-VPLS service-ID will
also be displayed. [210519-MI]
Subscriber • In Release 13.0.R4, the minimum quota for RADIUS-based credit control is reduced from
Management 900 seconds to 1 second for time credit and from 100 Mbytes to 1 byte for volume credit.
These minimum values are not realistic deployment values for multiple reasons, such as
effective statistics sampling period, statistics processing time, RADIUS message load, or
subscriber scale. For typical deployment scenarios, it is not recommended to implement
credit control quota values smaller than 60 seconds for the time quota, and for volume
quota, it is not recommended to use values smaller than the volume that can be consumed
in 60 seconds for that category (this is a function of number of queues and policers
monitored and their respective rates).

Enhancements
• Python support for Diameter NASREQ application messages (AAR/AAA) is now fully
supported. This feature was introduced in Release 13.0.R1.
• Release 13.0.R4 adds the ability to configure an authentication policy in WPP LUDB,
which is used for Web Portal Protocol (WPP) authentication if returned. The authentication
policy on group-interface is optional when WPP LUDB is configured; it will only be used
by WPP if there is no authentication policy returned from WPP LUDB. [182354]
• Release 13.0.R4 provides the support for subscriber-profile overrides via COA for
parameters of tier-1 scheduler in scheduler-policy referred to from the subscriber-profile.
See Limited Support Features and Enhancements for more information. [192710]
• The Web Portal Protocol (WPP) has been enhanced with following capabilities:
− the number of re-transmission for NTF-LOGOUT packet is configurable via CLI
− the number of re-transmission for ACK-AUTH packet is configurable via CLI
− re-transmission is configurable via CLI
− a clear command is added to remove WPP hosts in logout state [198574]
• Diameter multi-chassis redundancy is now available for the production network. This
feature was introduced in Release 13.0.R1.
VPLS • Release 13.0.R4 adds the ability to configure an IGMP-snooping mrouter port in the VPLS
of a Routed-VPLS service to its IP interface which sends all IGMP joins (and multicast
traffic) to the VPLS-service IP interface. This is useful to achieve a faster failover in
scenarios with redundant routers where multicast traffic is sent to systems on the VPLS
side of their Routed-VPLS services and IGMP-snooping is enabled in the VPLS service.
• When PIM-snooping is enabled within a VPLS service, all IP multicast traffic and PIM
messages will now be sent to any SAP or SDP binding configured with an IGMP-snooping
mrouter port. This will occur even without IGMP-snooping enabled. [184851]
VRRP/SRRP • Release 13.0.R4 adds SRRP/VRRP to the list of protocols that generate a
tmnxEqDataPathFailureProtImpact event when they are impacted by a data-path recovery
action. [208825]
IPsec • Release 13.0.R4 adds the ability to specify a domain name or an IPv4/v6 address as
subjectAltName in certTemplate of CMPv2 initial-registration request or certificate-
request. It also adds IPv6 address support for the admin certificate gen-local-cert-req
command. [185340]
• Release 13.0.R4 introduces the support for IKEv2 remote-access tunnel DHCP-based
address assignment. Prior to Release 13.0.R4, configuration of relay-proxy on private IPsec
tunnel interfaces, although not blocked in CLI, was not supported. [209178]
MC-IPsec • In Release 13.0.R4, upon switchover, the new master chassis will be polling for incoming
IPsec traffic on both public and private sides; only after receiving traffic, it will force a
CHILD_SA rekey, and the tunnels receiving ESP traffic will be rekeyed before other
tunnels.

Enhancements
• In Release 13.0.R4, the master and standby chassis will now use two different ESP SPI
ranges; Multi-chassis IPsec Mastership Protocol (MIMP) will decide which node uses
which range.

Facebook_RTP new Provides detection of Facebook voice traffic over
RTP.
NDMP new Provides detection of Network Data Management
Protocol over TCP.
QUIC new Provides detection of QUIC (Quick UDP Internet
Connections) over UDP. QUIC is a new communi-
cation protocol introduced by Google in Chrome
using UDP instead of TCP to transport
HTTP/HTTPs content.
SPDY new Provides detection of unencrypted SPDY over TCP.
Symantec Backup new Provides detection of Symantec Backup Exec over
TCP.
Taobao new Provides detection of Taobao over HTTP, SPDY
and TLS.
TLS_HTTP2 new Provides detection HTTP2 traffic over TLS. Prior
to the introduction of this new protocol HTTP2
encrypted flows were classified as TLS.
WhatsApp_RTP new Provides detection of WhatsApp voice traffic over
RTP.
Tango updated Provides improved detection of Tango over UDP.
• Release 13.0.R4 introduces QUIC protocol classification and QUIC SNI (Server Name
Indication) expression match capability in app-filter by reusing the existing http-host
match criteria. QUIC SNI expressions are also exported in the Cflowd comprehensive
records hostname field and recorded in the http-host-recorder. QUIC is a new
communication protocol introduced by Google in Chrome using UDP instead of TCP to
transport HTTP/HTTPS content. A significant percentage of the traffic generated by
Chrome browser to Google servers now uses this protocol; therefore, it is recommended to
upgrade the AA software using the AA Signatures Upgrade Procedure to keep the detection
up to date.
• Release 13.0.R4 supports the detection of existing protocols when TCP Fast Open is used
to initiate the TCP session. TCP Fast Open is an extension to TCP used to speed up the
opening of successive sessions between a client and server by avoiding the three-way TCP
initial handshake.
• Support for AA per-subscriber statistics for Distributed Subscriber Management (DSM)
AA subscriber types is now supported in CLI configuration and show commands. This

Enhancements
provides the support for application-group, Application and Charging Group counters on a
per-DSM subscriber basis. [205980]
• The ICAP url-filter policy now provides the capability to include an optional custom-x-
header field to the ICAP requests sent to the ICAP server. A predefined ASO characteristic
value is used to populate this new field allowing ICAP filtering policies on the server side
based on ASO value rather than subscriber name and effectively allowing traffic filtering
based on predefined packages to simplify the policy applicable to AA subscribers.
Cflowd • Release 13.0.R4 adds a tools command to display the contents of the Cflowd active flow
cache. The new command, tools dump cflowd cache, can display either the complete
contents of the active flow cache or an aggregated view which aggregates the flow entries
based on IP source and destination addresses, protocol and port numbers.
The CLI syntax is: tools>dump>cflowd>cache [all | aggregate] family{ipv4 | ipv6} {src-
dst-proto | src-dst-proto-port}. [199420]
OAM • An OAM-PM TWAMP-Light test session supports the configuration of the UDP source
port with config>oam-pm>session>ip source-udp-port udp-port-number in the range of
[64374–64383] to support Distributed TWAMP models (separation of Control-Client and
Session-Sender).
This command should only be used when deploying a distributed TWAMP model. This
command should not be used if the test functions only include native TWAMP-Light net-
work elements and no TWAMP TCP control channel. TWAMP-Light does not utilize the
use of TWAMP TCP Control channel. [191657]
• Locally-generated ETH-CFM PDUs generated from UP MEPs, vMEPs and MIPs can
utilize the EVPN Terminations as transport for EVPN services. The command cfm-mac-
advertisement is required to ensure that the locally-configured UP MEP, vMEP and MIP
MAC addresses on SAP, spoke-SDP and mesh-SDP are distributed through BGP. Shutting
down the MEP does not trigger a MAC withdrawal advertisement; the MEP’s deletion is
required for that action. [197962]
• The following OAM tools are now supported with a segment-routing tunnel:
− ping and traceroute within GRT
− SDP-level OAM tools: sdp-ping and sdp-mtu
• IPsec scale improvements
• IPsec tunnels per 7750 SR-c12 chassis
• Filter policy line card limits
• Redirect policy system limits
• OpenFlow per-service/interface flow table rule limit
• The combined SSH and Telnet session limit
• Subscriber management host scale per:
− system (running CPM5, chassis mode D)
− line card (on FP2- and higher-based line cards)

Enhancements
See Software Upgrade Notes and Known Limitations for more information.
• Event-Handling System (EHS) scale improvements by increasing the number of CLI
scripts, script policies and log filters
• Video ISA session scale improvements using MS-ISA
Release 13.0.R3
HW/Platform • The 1588 port-based timestamping feature on the p10-10g-sfp and p6-10g-sfp MDAs was
released in Release 12.0.R6 for laboratory environments only. This feature on these MDAs
has been modified to now support deployment in production networks. A hard reset of the
MDA is required to activate the modification. See also 202916 in Resolved Issues.
Routing • The output of show router tunnel-interface command is enhanced with the display of the
P2MP LSP type (RSVP or LDP) with which the interface is associated. [189407]
• Release 12.0.R4 introduced a change in CLI output to display route tags configured in
routing policies in hexadecimal instead of decimal format. In Release 13.0.R3, route tags
are now displayed in decimal format in policy-statement from and action accept
statements, and in the RIP, RIPng and OSPF show command output. Decimal format for
route tags is now used consistently in all CLI input and output. [193831]
BGP Multi-homing • The BGP multi-homing algorithm has been optimized with respect to the operation of the
site-min-down-timer as follows:
− If the site goes down on the designated forwarder but there are no BGP multi-homing
peers with the same site in an UP state, then the site-min-down-timer is not started
and is not used.
− If the site goes down on the designated forwarder but there are no active BGP multi-
homing peers, then the site-min-down-timer is not started and is not used.
− If the site-min-down-timer is active and a BGP multi-homing update is received
from the designated forwarder indicating its site has gone down, the site-min-down-
timer is immediately terminated and this PE becomes designated forwarder if the
BGP multi-homing algorithm determines it should be the designated forwarder.
[195483]
• The internal system timing mechanism related to BGP multi-homing has been enhanced to
use smaller intervals. This change does not affect the user-configurable timers; however, it
will improve the resolution experienced as part of the timing mechanism. [197222]
LDP • A new LDP Hello Adjacency Capability advertisement is introduced to enable or disable
the resolution of a FEC type over a given LDP interface. The following FEC types are
supported: unicast IPv4 FEC, unicast IPv6 FEC, mLDP IPv4 FEC (opaque types 1, 3, and
250, with IPv4 root LSR address), mLDP IPv6 FEC (opaque types 4 and 251, with IPv4
root LSR address).
By default, all FEC types negotiated via the LDP session are resolved on all LDP inter-
faces. If a given FEC type is enabled at the session level, it can be disabled over a given

Enhancements
LDP interface at the IPv4 or IPv6 adjacency level for all IPv4 or IPv6 peers over that inter-
face. If a given FEC type is disabled at the session level, then FECs will not be advertised
and enabling that FEC type at the adjacency level will not have any effect. The LDP adja-
cency capability can be configured on link Hello adjacency only and does not apply to tar-
geted Hello adjacency.
The LDP adjacency capability TLV is advertised in the Hello message as described in
draft-pdutta-mpls-ldp-adjcapability. It is used to restrict which FECs can be resolved over a
given interface to a peer. This provides the ability to dedicate links and data path resources
to specific FEC types. For IPv4 and IPv6 prefix FECs, a subset of ECMP links to a LSR
peer may each be configured to carry one of the two FEC types. An mLDP P2MP FEC can
exclude specific links to a downstream LSR from being used to resolve this type of FEC.
[206150]
Services General • Release 13.0.R3 adds the support for using an SDP with bgp-tunnel enabled for Epipe
spoke-sdp termination on IES and VPRN interfaces. [194468]
Subscriber • A new CLI flag ignore-df-bit in the PPP Local User Database (LUDB) ignores the do-not-
Management fragment (DF) bit for frames egressing the subscriber interface and fragments the frame
according to the applicable egress MTU. The DF bit is reset for the frames that are
fragmented. The CLI flag applies to PPPoE PTA and L2TP LNS frames only. [195644]
EPIPE/VLL • In Release 13.0.R3, the tools dump epipe-map-to-network command has been replaced
by the new command tools dump epipe-map-access-to-egress-port and enhanced to
support use cases including the use of endpoints for Epipe services. The original command
is deprecated.
This new command displays the egress port that will be used to transmit traffic associated
with the Epipe service. While the original command only supported Epipe services with a
single SAP and single SDP and would display the egress port associated with the SDP, the
new command supports Epipe services with the following combinations:
− SAP to SDP (with no endpoint configuration)
− SAP to SAP (with or without an Inter-Chassis Backup (ICB))
− SAP to SDP using endpoints with 1 or 2 SDPs
This command displays the egress port for traffic from SAP to egress SDP or to egress
SAP. It does not display the egress port for traffic from the SDP to egress SAP. This com-
mand also does not work with services that use policers or shared queues and also does not
support PBB services. [182135]
Cflowd • Release 13.0.R3 adds a new Cflowd option to export flow data using interface indexes
(ifIndex values), which can be used directly as the index into the IF-MIB tables for
retrieving interface statistics. Specifically, if the new config cflowd use-vrtr-if-index
command is enabled, then the ingressInterface (ID=10) and egressInterface (ID= 14) fields
in IP flow templates used to export the flow data to Cflowd v9 and v10 collectors will be
populated with the IF-MIB ifIndex of that interface. In addition, for v10 templates, two
new fields are added to the IP flow templates to present the Virtual Router ID associated
with the ingress and egress interfaces.

Enhancements
The default behavior remains the same as in prior releases, such that the ingress and egress
interface index will be populated using the SR OS global interface index, which is unique
on a system-wide basis but does require a separate MIB look up to determine the interface
index that is compatible with the IF-MIB tables. [198081]

League of Legends new Provides detection of League of Legends over
HTTP and TLS, and gaming over UDP.
LINE updated Provides improved detection of LINE over SPDY.
Viber updated Provides improved detection of Viber audio and
video traffic over UDP.
WLAN-GW • Release 13.0.R3 adds the support for managed routes to WLAN-GW group-interfaces. To
support this, the anti-spoof type of the group-interface has to be changed from the default
ip-mac to nh-mac. This is possible through new CLI: sap-parameters anti-spoof {ip-
mac | nh-mac}. With the new anti-spoof type, framed routes can be added using the
RADIUS attributes Framed-Route and Framed-IPv6-Route. To enhance the security for
MAC-only anti-spoof, uRPF support also has been added to WLAN-GW group interfaces.
[197111]
Release 13.0.R2
ARP/ND Snooping • Proxy-ARP now supports the following features in production networks:
and Proxy Support − Proxy-ND
− Proxy-ARP dynamic-arp-populate (IP->MAC entries learned from snooped
ARP/GARP messages received in SAPs/SDP-bindings).
This feature was introduced as a limited-support feature in Release 13.0.R1.
Application • Release 13.0 R2 supports a new version of the isa-aa.tim file that enables new and updated

Enhancements

QQ updated Provides improved detection of QQ traffic over
HTTP and TCP.
Weixin updated Provides improved detection of WeChat traffic over
HTTP and TCP.
WLAN-GW/WiFi: • The VLAN to WLAN-GW IOM/IMM steering via internal Epipe feature is now supported
VLAN to WLAN- for production networks. This feature was introduced as a limited support feature in
GW IOM/IMM Release 13.0.R1.
Steering via
Internal Epipe
Release 13.0.R1
Release 13.0.R1 also includes all enhancements available in Releases 12.0.R2 to 12.0.R8. Refer
to the SR OS 12.0.R8 Release Notes for enhancements available in Releases 12.0.R2 through
12.0.R8.
HW/Platform • The CLI now displays “Transceiver Status” in show port detail. [171306]
RADIUS • A new timer, “down-timeout”, is used to declare a RADIUS server “out-of-service”. A

RADIUS server is declared “out-of-service” if it fails to respond to RADIUS requests
within the “down-timeout” interval. By default, the value of the “down-timeout” is the
number of retries multiplied by the timeout interval. Each host will use the configured
timeout and retry value under the AAA RADIUS server policy; timeout refers to the
waiting period before the next retry attempt and retry refers the number of times the host
will attempt to contact the RADIUS server. If a RADIUS server is declared “out-of-
service”, the host pending retry attempts will move on to the next RADIUS server.
[193009]
System • The NTP time recovery process has been augmented to smoothly incorporate leap second
events into the node timebase. This includes protection against race conditions with NTP
messaging near the UTC midnight on the leap second day.
• The behavior of session logs (logs with to session in their configuration) has been
enhanced in several ways. All of the log configuration is now saved in an admin save
except for the to session configuration. The to session configuration is non-persistent and
will no longer cause a '*' (the unsaved change indicator) to appear at the beginning of the
CLI prompt.
• On systems with APEQs, in conditions where all of the fans have failed or are absent from
the chassis, the system temperature could increase to unacceptable levels. A new
functionality has been added to the APEQs, where they will bring the system down within

Enhancements
three (3) minutes if the fans have failed or their presence cannot be detected. User
intervention is required to recover the system. [162664]
• In Release 13.0.R1, new internal thresholds and resulting log or SNMP trap messages have
been added to monitor the IOM next-hop resources. The existing error message when the
next-hop resource is exceeded has been updated and two new messages have been added to
signal when the resource reaches 90% utilization and another when it has dropped below
85% utilization. [163875]
• The auto-generated timestamp used in script result filenames (used, for example, by CRON
and EHS) has been enhanced to include microseconds.
• Users executing unauthorized CLI commands will now generate an event that will be
captured in the system log. [171199]
• Release 13.0.R1 has added three new AES-CTR ciphers to SSHv2: AES128-CTR,
AES192-CTR, and AES256-CTR. These new ciphers will help to improve SR OS SSHv2
security. [173803]
• Release 13.0.R1 introduces additional checks on Inter-card Communication messages to
prevent card resets in case of bit corruptions in these messages. [183193]
LAG • Support for mixed port-speed LAG was enhanced to allow mixing of 10GE WAN-PHY
ports with 100GE ports. A small difference between WAN-PHY and LAN-PHY in port
speed is ignored; thus, for example, a 100GE port is considered to be ten times the
bandwidth of 10GE WAN-PHY port for all weight/port-speed based functionality (such as
QoS or hash). [192095]
Routing • Release 13.0.R1 introduces the option to add a description to an aggregate route. [175397]
Route Policies • Release 13.0.R1 enhances the route policy source-address command to accept a prefix-
list instead of just a single IP address. [171519]
IPv6 • It is now possible to remove a manually-configured IPv6 Link-Local Address (LLA) on an

IP interface. Previously, removing manually-configured LLA required the operator to
completely remove IPv6 configuration on the interface using the no ipv6 command.
Operators may now use the ipv6 no link-local-address command to remove a manually-
configured LLA, and the system will regenerate an EUI-64 LLA for that interface.
[175057]
DHCP server • The support for leasequery has been added. When the allow leasequery option is set to
false:
− the server will drop leasequery requests (as before)
− no leasequery counters will be increased even when a leasequery request is received
(as before)
When the allow leasequery option is set to true:
− the server will reply to leasequery by client-ID
− queries with missing options or malformed queries will also get a reply with a
corresponding status code

Enhancements
The options OPTION_LQ_RELAY_DATA, OPTION_LQ_CLIENT_LINK, are not sup-

ported. [193869]
DHCP • Release 13.0.R1 adds support to insert NAS-Port (containing tunnel source/destination) in
a DHCP option in case of Layer-2 wholesale. The option is then included in access-request
message to AAA. [198441]
Python • Release 13.0.R1 introduces python-policy support for DHCPv4 and DHCPv6 relay on
service SAP (non-ESM) interfaces. The highlights of this enhancement are:
− Python module alc.dhcpv4 and alc.dhcpv6 are supported
− Python module alc.dtc is supported except alc.dtc.setESM() is not supported
[191818]
RIP • In Release 13.0.R1, RIP and RIPng have been enhanced to allow RIP updates to be sent as
unicast messages, instead of multicast or broadcast messages. This is enabled by specifying
a unicast address instead of the interface name when creating the RIP/RIPng neighbor. In
addition, the send unicast command must also be enabled to activate the unicast
advertisements. [168243]
IS-IS • The functionality to set overload state due to an SFM failure that reduces forwarding
capacity has been extended with the support for IS-IS. Setting overload enables a router to
still participate in exchanging routing information, but routes all traffic away from it.
Previous releases starting with Release 8.0.R1 supported OSPF only.
Overload is now set for both OSPF and IS-IS using the config router single-sfm-overload
CLI command for global router protocols, or with the single-sfm-overload CLI command
within a VPRN. The conditions to set overload are as follows:
− 7750 SR-c12/7/12 and 7450 ESS-6/6v/7/12: protocol sets overload if one of the
CPM/CFMs fails.
− 7950 XRS and 7750 SR-12e: protocol sets overload if two or more SFMs fail.
[171604]
• IS-IS now enters the overload state if adding routes to the hardware FIB fails, or the
protocol reaches the configured maximum route limit in a VPRN (set with maximum-
routes or maximum-ipv6-routes). Previous releases would restart IS-IS every 30 seconds.
To clear overload for IS-IS, use the clear router isis overload CLI command. [171714]
OSPF • OSPF now enters the overload state if adding routes to the hardware FIB fails, or the
protocol reaches the configured maximum route limit in a VPRN (set with maximum-
routes or maximum-ipv6-routes). Previous releases would restart OSPF every 30
seconds. To clear overload for OSPF, use the clear router ospf overload CLI command.
To clear overload for OSPFv3, use the clear router ospf3 overload CLI command.
[172076]
BGP • Release 13.0.R1 adds BGP next-hop information to the display of BGP routes in the
routing table and FIB. [141814]

Enhancements
• Release 13.0.R1 improves third-party next-hop handling in BGP and also makes it
configurable. [165801]
• Release 13.0.R1 allows the policy-based export of the active/installed route to a peer that
has BGP advertise-inactive enabled in its configuration. [167175]
• Release 13.0.R1 extends the show router bgp routes command to allow filtering of
IP-VPN routes based on the combination of community and prefix/route-distinguisher.
[172384]
• Release 13.0.R1 changes the BGP FlowSpec implementation to comply with draft-haas-
idr-flowspec-redirec-rt-bis-00. This is an important draft to ensure interoperability with
other vendors when using the redirect-to-VRF action. The standards that originally defined
this action (RFC 5575) did not specify how the type of the route-target should be inferred.
[174598]
mLDP In-Band • Release 13.0.R1 adds the option to configure ipv4 and ipv6 to the following command:
Signaling config>router>pim>if>p2mp-ldp-tree-join [ipv4][ipv6]
The ipv4 and ipv6 keywords are optional keywords; if no keyword is chosen, then ipv4 is
assumed for backward compatibility.
IMPM • When a 7750 SR or 7450 ESS system is equipped with an SFM5, the default values used in
the mcast-capacity and redundant-mcast-capacity commands (under config>mcast-
mgmt>chassis-level>plane-capacity) are set to 87.5%. [201913]
QoS • A new statistic in the show service id service-id sap sap-id sap-stats output displays the
number of valid packets received on SAP ingress policers and queues (used on that SAP or
subscribers on that SAP), and on any related ingress queue group policers and queues. This
is particularly useful to display SAP-level traffic statistics when forwarding classes in a
SAP ingress policy have been redirected to an ingress queue group.
The statistics do not include any packet-byte-offset that may have been set in the SAP
ingress QoS policy or the ingress queue-group template. This is applicable to all services
and is supported for all hardware.
• The number of policers configurable as a SAP ingress and SAP egress QoS policy has been
increased to 63 for each. This allows a larger number of policers to be used in the IPv4 and
IPv6 criteria action statements ingress. Forwarding-class mapping capabilities have not
changed though forwarding classes can be mapped to any policer identifier.
• SAP egress QoS has been enhanced to allow traffic to be classified directly to an egress
policer. This is supported using the action parameter in the ip-criteria and ipv6-criteria
statements. Policed traffic continues by default to exit through a forwarding-class-mapped
queue in the egress policer-output-queues queue group, or alternatively it can be directed
to a local queue, a queue in a user-defined queue group, or it can exit using the queue
mapped by its forwarding class if the use-fc-mapped-queue is specified.
This is supported on all FP2- and higher-based hardware, excluding on a 7750 SR-a4/a8 or
when HS-MDAv2 is used.
• The ability to override the parent weight and CIR-weight configured on ingress and egress
tier 2 and 3 schedulers, and on a tier-1 egress scheduler with a parent-location vport, has

Enhancements
been added to SAPs and multi-service sites. This is supported on all hardware but is not
applicable to an HS-MDAv2.
• Support has been added to allow a packet-byte-offset to be applied to SAP, subscriber and
queue group ingress queues. This allows the packet size used for both shaping and
accounting to be either increased or reduced. This is supported on FP2- and higher based
hardware and ignored on FP1-based hardware.
• The maximum value for the substract parameter used in a packet-byte-offset statement is
now 64 for all egress uses of this parameter, including the related overrides. Note that the
minimum resulting packet size used by the system is one (1) byte, or 64 bytes with an
HS-MDAv2, regardless of the setting of the substract parameter.
• The configuration of SAP ingress and egress QoS policies has been simplified by allowing
IPv4 prefix lists to be used for matching in IP criteria statements. This is supported when
applying these policies to SAPs.
• The maximum rate configurable for queue PIR and CIR rates in a SAP ingress and egress
policy (when used with SAP or subscribers), and in an ingress and egress queue group,
have been increased to 2000 Gb/s.
If the rates at ingress exceed the port capacity, or exceed the FP capacity with per-fp-ing-
queuing configured, the rates are set to max. At egress, if the rates exceed the port capacity
(including the egress-rate setting) they are set to max. As a consequence, the maximum
queue rate used can change and hence the behavior of some existing configurations can
change. This also impacts the use of percent-rates with no parent or a max-rate parent, or
the use of the advanced-config-policy with a percent percent-of-admin-pir.
Rates greater than the above (capped) rates are only relevant when configured on a queue
which is part of a distribute or port-fair mode LAG spanning multiple FPs.
The related queue MBS and CBS maximum values are increased to 1GB, which are con-
strained by the pool size in which the queue exists and for the MBS also by the shared pool
space in the corresponding megapool. Their default values remain at the maximum of 10ms
of the PIR or 64Kbytes for the MBS and the maximum of 10ms of the CIR or 6K bytes on
an FP2 and 7680 bytes on an FP3 for the CBS.
In addition, the following rates have been increased to 3200 Gb/s:
− a scheduler PIR and CIR rates in a scheduler policy
− the maximum rate, a level’s PIR and CIR rates and a group’s PIR and CIR rates in a
port-scheduler policy
− the aggregate rate applied on egress Ethernet port queue groups, Vports, SAPs, multi-
service sites and encap groups (but not on egress subscriber profiles, IGMP/MLD
H-QoS adjustment rates, ANCP rates or WLAN gateway rates)
All queue, scheduler and egress scheduler overrides relating to the above rates have also
been increased to the corresponding value.
Note that due to the changes in this implementation, there may be small differences in the
resulting rates, MBS and CBS compared to the previous implementation.
This is supported on FP2- and higher-based hardware but is not applicable to the
HS-MDAv2.
• The IPv6 matching criteria within a SAP ingress QoS policy has been enhanced to include
matching on fragmented packets, including matching only on the first or non-first
fragments.

Enhancements

• The entry for “QoS Internal Schedulers” has been removed from the output of the tools
dump system-resources command as the system ensures that sufficient internal schedulers
are available so this resource no longer needs to be monitored. [184405]
• The show card slot-number cpu command has been enhanced to display the CPU
information of two additional IOM process groups: H-QoS Algorithm and H-QoS
Statistics. As the naming implies, the first is responsible for running the actual algorithm
and executing the result while the second collects the offered statistics from the queues.
Note that on line cards with a Multicore CPU, the capacity usage of the H-QoS statistics
process group will always be seen to be near to 100%; this is expected as it constantly tries
to run as fast as possible when unused processor cycles are available, and it is not detrimen-
tal to the running of other processes on the line card. [188179]
Filter • Release 13.0.R1 introduces enhanced show and debug CLI support for filter policies. The
existing filter commands under show>filter and tools>dump>filter>resources have been
enhanced to provide more detail on how filter policies are allocated, how much resource is
being consumed currently by filter policies, and which filter policies or filter policy entries
consume the most resources. To display the extra information, some pre-Release 13.0.R1
displays have been modified to introduce new or modified headings. Any external tools
parsing through filter show and tools displays must be verified and modified accordingly
prior to an upgrade.
• Release 13.0.R1 introduces the support for PBR redirect action forward {sap | sdp} for
IPv6 filter policies for VPLS services. This action has been supported previously in IPv4
filters only. [166644]
• Release 13.0.R1 adds the support for SCTP source/destination match in IPv4 and IPv6
ingress line card filter policies. SCTP port match supports same inputs as TCP/UDP port
match. To specify SCTP port match, the protocol for filter entry match must explicitly
define SCTP. The SCTP match programming is only supported using CLI/SNMP
management. [182939]
Policy • It is now possible to use regular expressions with the site of origin (SOO) extended
community in community-lists. [120229]
• Release 13.0.R1 extends the policy-test command to accept up to fifteen (15) policy names
so that the result of a chain of policy statements on a selected set of BGP routes can be
evaluated. [184487]
Subscriber • The maximum number of RADIUS servers in a RADIUS server policy has been increased
Management from five (5) to sixteen (16). [131980]
• Release 13.0.R1 adds the support for configurable NSAPI values on WLAN-GW. [166216]
• Release 13.0.R1 adds the support to report the VLAN tag received in GRE-encapsulated
Layer-2 frame to RADIUS in authentication and accounting messages. [173033]
• WLAN-GW now includes an APCO (as per 3GPP Release 11) in session-create-request
message instead of PCO, to request DNS from PGW. [174786]
• The output of the show subscriber-mgmt statistics command has been enhanced with
updated and new counters such as DHCPv6 (PD) managed route, IPv6 static hosts, IPoE

Enhancements
sessions, Basic Subscriber Management (BSM). New Total Subscriber hosts and Total
System Hosts Scale counters can be used to match against per line card and system scaling
limits. All counters have peak values that can be cleared and are available in a MIB for
SNMP access. [190452]
• Release 13.0.R1 adds multicast as an option for per-host-replication under subscriber-
management igmp-policy. By default, per-host-replication will use unicast to deliver the
mulitcast content directly to the host. Enabling the multicast option will send the multicast
content using a multicast destination address and the multicast statistics will be counted
against the subscriber's queues.
VPLS • Release 11.0.R1 introduced the support for IPv4 multicast routing in a Routed-VPLS
service where the source is located on the IP interface side of the service with receivers on
the VPLS side of the service. When IGMP is configured on the IP interface, it was
mandatory to enable IGMP-snooping in the VPLS. This constraint has been removed so
that IGMP can now be configured on the IP interface without needing IGMP-snooping to
be enabled in the VPLS service.
• The pw-template has been enhanced in Release 13.0.R1 with the Spanning-Tree-Protocol
(STP) and Layer-2 Protocol Tunneling (L2PT) commands already supported under SAPs
and SDP-bindings. STP and L2PT commands may be added to pw-template in VPLS
services when BGP-AD and/or BGP-VPLS are used.
• The monitor-oper-group group-name statement has been added under the
config>service>vpls>bgp>pw-template-binding context. The BGP-AD auto-instantiated
spoke-SDP bindings can now monitor an existing oper-group and drive their status based
on the configured oper-group. [172167]
IPsec • Certificate authentication and Diffie-Hellman computation for IKE protocol has been
further optimized; as a result, the setup performance of IPsec tunnels is increased.
• Release 13.0.R1 introduces the following new algorithms to IPsec:
− PRF_AES128_XCBC as IKEv2 pseudorandom function
− AUTH_AES_XCBC_96 as IKEv2 integrity Algorithm
− AUTH_AES_XCBC_96 as ESP integrity Algorithm [136711]
• Release 13.0.R1 allows the system to send unsolicited IKEv2 configuration attributes to
clients if they are available in RADIUS Access-Accept. [168065]
• Release 13.0.R1 allows the system to support a combination of EAP and one other auth-
method on the same IPsec-GW:
− eap + psk-radius
− eap + cert-radius
− eap + psk-radius or cert-radius
This behavior is enabled by configuring auth-method as auto-eap-radius, along with con-
figuration of auto-eap-method and auto-eap-own-method. [173212]
• Release 13.0.R1 allows the system to print out the content of the notification data field of
IKEv2 Notify payload in the debug IPsec output. [175834]
• Release 13.0.R1 allows the system to return secondary IPv4 and IPv6 DNS server
addresses to IKEv2 remote-access client via IKEv2 configuration payload. [175866]

Enhancements
• Release 13.0.R1 introduces the following new behavior regarding the user-password
attribute in access-request when authenticating IKEv2 remote-access tunnel:
− if auth-method is psk-radius, then the system will include the user-password with
tunnel's psk as the value
− if auth-method is any other RA tunnel method (eap or cert-radius): then the system
will only include the user-password when password is configured in IPsec radius-
authentication-policy. [175869]
− Release 13.0.R1 extends the VPRN route types that can be used to reach the
destinations of IP tunnels (IP-in-IP or GRE). It is now possible to use VPRN routes
with tunneled next-hops (to remote PEs). [178615]
TMS • Release 13.0 supports the configuration of a filter applied to the ISA-TMS tms-interface
off-ramp ingress CLI context allowing TMS-generated traffic (typically challenge
packets) to be redirected to the Base routing table via a new redirect-to-vrf command.
This feature allows for correct routing of TMS-generated challenges back to source IP
address where VRF is being used to off-ramp traffic (as opposed to base table being used to
off-ramp traffic), and thus does not contain source routes back to the IP source of off-
ramped traffic. [172653]
NAT • The source IP address of an L2-Aware NAT subscriber has been added to the MAP/FREE
event logger.
• Security nonce has been added to the PCP Opcode Map and Get.
• Nonce restriction in PCP GET with NEXT option has been removed. This will allow PCP
clients to query the PCP server’s existing PCP mappings, without having to know the
nonce with which the mapping was initially created in accordance with draft-cheshire-pcp-
unsupp-family-06.
• Returned error code “CANNOT_PROVIDE_EXTERNAL” has been replaced with error
code “MALFORMED_OPTION for MAP opcode with PREFER_FAILURE option and
unspecified Suggested External Port and/or Suggested External Address field”, according
to RFC 6887.
• Release 13.0.R1 introduces debug capability for PCP (debug router pcp pcp-server name
packet).
• Port-forwards, Lawful Intercept (LI) entries and deterministic maps/prefixes have gained
an operational state. In the event that the NAT subscriber resources are temporarily
exhausted, the port-forwards, LI entries and deterministic map/prefixes temporarily
become non-operational. After the resources are freed, the entities in question
automatically transition into an operational state that can be observed via show commands.
Consequently, new traps have been introduced: tmnxNatFwd2OperStateChanged,
tMirrorLiNatLsnSubOperStateCh, tMirrorLiNatL2awSubOperStateCh,
tmnxNatDetMapOperStateChanged and tmnxNatDetPlcyOperStateChanged.
• Output of the show service nat port-forwarding-entries has changed and now includes
the operation state of the port-forwards.
• Output of the show li li-source source-id command has changed and now includes the
operation state of the LI in NAT.

Enhancements
• Output of the show service nat summary has changed and now includes additional
information about subscriber identification, NAT redundancy and NAT policies. [189366]
Application • App-Service-Options characteristics and values can now be included in the AA-subscriber
Assurance custom accounting records. Once configured, the accounting record will include all app-
service-options characteristics and values applied to each subscriber.
• The system automatically exports the IP-family information in Cflowd Volume IPFIX
records. This provides additional information to the operator for data-mining use cases to
understand traffic distribution between IPv4, IPv6, DS-Lite, 6RD, and Teredo at the
network level or per application.
• The system automatically exports the Operating System version in the Cflowd
Comprehensive IPFIX records. This new capability provides additional information to the
operator for data-mining use cases to understand traffic distribution per major/minor
release of a given Operating System.
• Release 13.0.R1 now automatically monitors success and failure notifications using HTTP
notification. In case the notification is not successfully displayed the system will
automatically attempt to notify the next candidate flow instead of waiting for the next
notification interval. This enhancement requires the operator to update the notification
script and modify the AA Policy in order to enable the http-match-all-req for HTTP
requests sent to the messaging server.
• Release 13.0.R1 adds a minimum-isa-generation command to configure the scale
parameters for the ISA group.
− When minimum-isa-generation is configured as one (1), the Group and per-ISA
limits are the MS-ISA (ISA1) scale.
− If there is a mix of MS-ISA and MS-ISA2, the minimum-isa-generation must be left
as one (1).
− When minimum-isa-generation is configured as two (2), the per-ISA resource limits
(as per show isa application-assurance-group 1 load-balance) will increase to MS-
ISA2 limits.
• Release 13.0.R1 adds network-address as an app-filter match criteria to allow IP prefix
list-based identification of traffic such as for on-net vs. off-net traffic [184415]
• Release 13.0.R1 adds a configurable export method for per-subscriber aggregate statistics.
The options are no-export and export via an XML accounting policy (XML export is only
supported in residential and VPN aa-sub-scale modes). [187025]
• Release 13.0.R1 enhances the Gx Diameter interface to support 3GPP release 12. 3GPP
Release 12.0 does not make use of ADC rules (as per release 3GPP R11) on the Gx
interface and instead integrates some of ADC functionality into PCC rules. AA supports
both models. [189845]
• Release 13.0 R1 supports a new version of the isa-aa.tim file that enables new and updated
protocol signatures and applications. The new and updated protocols in this release are

Enhancements

DTLS new Provides detection of DTLS 1.0, DTLS 1.2, DTLS
X.509 certificate subject common and organization
name string matching and DTLS session resump-
tion using session ID.
Flow Export new Provides detection of NetFlow v5/v8/v9, IPFIX
over UDP and sFlow v5.
Snapchat new Provides detection of Snapchat over TLS.
JustinTv updated This protocol has been updated such that it now
detects only Twitch Video Streaming (both Twitch
and JustinTv services belong to the same parent
company, Twitch Interactive).
OpenVPN updated Provides detection of Hotspot Shield over UDP and
TCP.
Cflowd • In Release 13.0.R1, a new option manual-export has been added to the Cflowd collector
configuration options allowing flow exports to be trigger-based. Currently, Cflowd will
automatically export flow data as the traffic flow expires due to flow timeouts. With this
option enabled, these flows will not automatically be sent but instead will be kept in the
Cflowd cache until the manual trigger is issued to generate the flows. At that time all
expired flows will be set to the associated collector as quickly as possible. This new option
does not change the behavior of the system if the cache size is exceeded, in which case the
normal overflow actions will be taken. [172569]
OAM • DMM support for 10-second (10000 ms) probe interval for OAM-PM configured tests has
been added. [182865]
• SRRP scaling on CPM3 and above
• IPsec IKEv2 chassis limit
• NAT on MS-ISA2
• LAG scaling on the entire system

Limited Support Features and Enhancements
Limited Support Features and Enhancements

This section describes the SR OS features that are intended for laboratory use only (not for the
production network environment).
See also Unsupported Features and Known Limitations for more information about features that
may not be fully supported.
HW/Platform
Virtualized The virtualized Simulator (vSim) is a product that taps the potential of network function
Simulator virtualization (NFV). This product is intended to be used as a laboratory tool to fully simulate
the control and management plane of an SR OS node. The vSim is not intended to be used in a
production network environment and the forwarding plane is limited to 250 pps per interface.
This feature was introduced in Release 12.0.R4.
Services
XMPP Support on The provisioning of filter entries from VSD is NOT supported in production networks and can
DC PE for Filters only be used in controlled laboratory environments. If a filter entry is sent from VSD and added
(Fully-Dynamic to the running configuration by a Python script, the laboratory user is advised NOT to admin
Model) save the configuration in order to avoid issues. This feature was introduced in Release 13.0.R4.
Subscriber
Management
Gx – PCC Rules Gx support has been added for fully-defined rules that can be constructed on PCRF and applied
to the subscriber host. This feature should only be used in a laboratory environment and not in
a production network. This feature was introduced in Release 13.0.R4.
Subscriber-profile Subscriber-profile overrides via CoA for parameters of tier-1 scheduler in scheduler-policy
Overrides via CoA referred to or from the subscriber-profile should only be used in a laboratory environment and
not in a production network. This enhancement was introduced in Release 13.0.R4.

Unsupported Features
The following tables summarize the features that are not supported on certain SR OS platforms
(marked by an X where unsupported). All SR OS features are supported on all platforms unless
otherwise listed in the table below.
Some platforms do not support ISA applications using MS-ISAs; see also Release 13.0.R10
Supported Hardware and Usage Notes for more information.
Hardware
Table 22. Unsupported Hardware Features
7450 ESS without mixed mode
7450 ESS with mixed mode

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
Chassis modes X X1 X X X
Channelized and TDM interfaces X X X X
ATM interfaces, MDA, and services X X X X
ASAP MDAs and associated interface types X X X X
CES MDAs and associated interface types X X X X
IEEE 1588 PTP X X2 X
IEEE 1588 port-based timestamping X X X
Sub-second CCM-enabled MEPs X
SONET/SDH interfaces X X X
VSM Cross-Connect Aggregation (CCA) and CCA Group (CCAG) X X X X X3
1. The 7750 SR-12e contains the same feature set as the 7750 SR in chassis mode D. Chassis mode concept is not present on
the 7750 SR-12e.
2. Not supported on 7750 SR-c12 with CFM-XP.
3. VSM/CCA is only supported on 7750 SR VSM MDAs in IOM3-XP when mixed mode is enabled.

System
Table 23. Unsupported System Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
BITS input port redundancy X1
BITS Out support X1
Centralized (CPM-based) CPU-Protection X2 X2 X2
Ingress Multicast Path Management X X X
Major ISSU X X X
Minor ISSU X X3 X
Soft Reset X X3 X
System Alarm Contact Inputs X X X X X X
OOB Management Ethernet Port Redundancy X X X
1. Supported on the 7750 SR-c4 but not supported on the 7750 SR-c12.
2. Note that Distributed CPU Protection (DCP) is supported.

Quality of Service
Table 24. Unsupported QoS Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
Named Pools (QoS) X X X X
Ingress shared queuing (Dual-Pass) X X1
Policers (except for Distributed CPU Protection) X
1. Not supported on 400G FP3 line cards.
Routing
Table 25. Unsupported Routing Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
BGP for forwarding unicast packets in GRT X
BGP RFC 3107-labeled routes for forwarding unicast packet in GRT1 X
ABR/RR capability for BGP RFC 3107-labeled routes2 X

Cflowd X
IPv6 routing (unicast and multicast, 6PE, 6VPE, QoS criteria matching
X
within a VPLS or Epipe service)
IP Multicast routing and forwarding X
• Protocols: PIM, MSDP, and IGMP X
• MVPN X
• P2MP LSP for forwarding multicast packet in GRT and in MVPN3 X

1. BGP RFC 3107-labeled routes are supported in L2 services only.

2. LDP-BGP stitching is supported.
3. P2MP LSP is supported in VPLS.
MPLS
Table 26. Unsupported MPLS Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
GMPLS UNI X X X X
Services
Table 27. Unsupported Services Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
Arbor TMS: Threat Mitigation Services1 X X X X X
Circuit Emulation services (for example, Cpipe SAPs) X X X
new-qinq-untagged-sap configurability for :*.0 and :0.0 SAPs X 2
Full VPRN support X

Frame Relay interfaces and services (for example, Fpipe SAPs) X X X X
IP Mirroring X
Tunnel services (IPsec, GRE tunnel termination)3,4 X X X5 X X

Table 27. Unsupported Services Features (Continued)

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
IPv6 tunnel services (IPsec, GRE tunnel termination)3,4 X X X5 X X
G.8031 (Ethernet tunnel support) X
Multi-Chassis features using isa-tunnel with MS-ISA6 X X X X
sFlow X X X X X
Spoke termination on L3 (IES/VPRN) interfaces X
Video services (Retransmission and Fast Channel Change, Video Qual-
X X X X X8 X8
ity Monitoring, Local/Zoned Ad Insertion)1,7
1. Requires an MS-ISA/MS-ISA2/MS-ISM (along with -E variants on the 7750 SR).
2. This feature is always “on” for the 7950 XRS.
3. Requires an MS-ISA/MS-ISA2/MS-ISM.
4. Requires an isa-tunnel/isa2-tunnel application license.
5. Not supported on 7750 SR-c4 only.
7. Requires an isa-video application license.
8. Not supported for local or zoned ad insertion video service only.
Subscriber Management
Table 28. Unsupported Subscriber Management Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
IPv4 local DHCP Server X
IPv6 local DHCP Server X X

Table 28. Unsupported Subscriber Management Features (Continued)

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
L2TP LNS1,2 X X X X
port-policy command1,2 X X
1,2 X X X3 X
NAT
WLAN gateway (WLAN-GW)1,2 X X X X X X
Subscriber Management—Routed CO (VPRN/IES subscriber inter-
X X
faces)
Subscriber Management—Bridged CO (VPLS) X
2. Requires an isa-bb/isa2-bb application license.
3. Supported on the 7750 SR-c12 but not on the 7750 SR-c4.
Application Assurance
Table 29. Unsupported AA Features

7750 SR-1e/2e/3e
7750 SR-c4/c12
7750 SR-a4/a8
7750 SR-7/12
7750 SR-12e
7950 XRS
Feature
Application Assurance1 X X
AARP X2
1. Requires an MS-ISA/MS-ISA2/MS-ISM (along with -E variants on the 7750 SR) and an isa-aa/isa2-aa application license.

Deprecated Features
Deprecated Features
Release 13.0.R10
No features have been deprecated in Release 13.0.R10 since Release 13.0.R9.
Release 13.0.R9
Release 13.0.R8
Release 13.0.R7
Release 13.0.R6
Release 13.0.R5
Release 13.0.R4
Release 13.0.R3

Deprecated Features
Release 13.0.R2
Release 13.0.R1
This section describes the SR OS features that have been deprecated in Release 13.0.R1.
7710 SR • The 7710 SR-c4/c12 is no longer supported in SR OS starting in Release 13.0.R1.

Changed or Deprecated Commands

This section describes the SR OS commands that have been changed or deprecated. See also
Software Upgrade Procedures for more information about the behavior of commands or
parameters that have been modified or deprecated between releases.
Release 13.0.R10
No commands have been changed or deprecated in Release 13.0.R10 since Release 13.0.R9.
Release 13.0.R9
Release 13.0.R8
This section describes the SR OS commands that have been renamed or deprecated in Release
13.0.R8.
ISA
Application
Commands
NAT Commands • The group parameter is renamed to nat-group in the following CLI commands. [210642]
Command Prior to Release 13.0.R8 Command in Release 13.0.R8

show isa nat-system-resources group group- show isa nat-system-resources nat-group
id member [1..255] nat-group-id member [1..255]
tools dump nat isa resources group group- tools dump nat isa resources nat-group
id member [1..255] nat-group-id member [1..255]
Release 13.0.R7

Release 13.0.R6
Release 13.0.R5
13.0.R5.
BGP Commands • Release 13.0.R5 supports dynamic BGP peering for both ESM hosts and non-ESM hosts
(such as regular routers). To avoid confusion between the two, the command dynamic-
peer for ESM hosts, configured under BGP group, has been changed to esm-dynamic-
peer.

configure configure
service vprn service-id service vprn service-id
bgp bgp
group name [dynamic-peer] group name [esm-dynamic-peer]
Release 13.0.R4
13.0.R4.
Filter Commands • Release 13.0.R4 introduces changes to the ACL filter policy commands. The action
command (with all types and related parameters defining), used to define an action to be
performed on a packet matching IPv4/IPv6/MAC ACL policy entry, has been deprecated
and replaced by a new action command that allows the operator to enter a new CLI context
under which individual actions can be configured using drop, forward, gtp-local-
breakout, http-redirect, nat, and reassemble action type commands and their respective
parameters.
The operational impact of the action command restructuring is as follows:
− Because all command and parameter names were preserved, any ACL configuration
prior to Release 13.0.R4 remains valid and results in the same configuration result for
all cases except the following:
Prior to Release 13.0.R4, an operator was able to use CLI, SNMP, or NETCONF to
configure an IP, IPv6, or MAC filter policy entry’s action without explicitly
specifying the action type. The system would interpret such configuration as “action
drop”. This functionality is no longer supported and action type must always be
explicitly specified using new action-type commands under new action context.
Loading an old configuration file that does not explicitly configure action type will
either fail or will result in a different behavior (a filter entry will not be activated as no
action is configured). The operator must ensure that any old configuration file always

explicitly configures action type drop for every filter policy entry action missing
explicit drop keyword. During an ISSU upgrade to Release 13.0.R4 or newer, the
system automatically converts the “action” command with no type specified to
“action drop” for all ACL filter types.
− Starting with Release 13.0.R4, admin save and info commands will save or display
filter entry action configuration in a multi-line format (as illustrated below).
− CLI configuration continues to accept a single line format to specify an action with its
type and related parameters.

configure configure
filter {ip-filter | ipv6-filter | mac- filter {ip-filter | ipv6-filter | mac-
filter} filter}
entry entry
action action
drop
... ...
action drop [optional parameters] action
drop [optional parameters]
... ...
action forward [optional parame- action
ters] forward [optional parameters]
... ...
action http-redirect [optional action
parameters] http-redirect [optional parame-
ters]
... ...
action nat [optional parameters] action
nat [optional parameters]
... ...
action gtp-local-breakout action
gtp-local-breakout
... ...
action reassemble action
reassemble
Subscriber • In Release 13.0.R4, the pd-managed-route command is enhanced with a next-hop

Management {ipv4 | ipv6} parameter. When upgrading to Release 13.0.R4, the configuration will be
Commands converted as follows:
CLI contexts:
− config>service>ies>sub-if>grp-if>ipv6>dhcp6>
− config>service>vprn>sub-if>grp-if>ipv6>dhcp6>
− config>service>ies>sub-if>ipv6>dhcp6>
− config>service>vprn>sub-if>ipv6>dhcp6>


configure configure
service service
ies service-id ies service-id
subscriber-interface ip-int-name subscriber-interface ip-int-name
group-interface ip-int-name group-interface ip-int-name
ipv6 ipv6
dhcp6 dhcp6
pd-managed-route pd-managed-route next-hop ipv6
OAM Commands • TWAMP Light reflector range [1024–65535] has been restricted to [64364–64373] to
prevent UDP port allocation collisions. A configuration attempting to load with the
twamp-light reflector udp-port udp-port-number create outside of this range will cause
the reflector to fail the no shutdown activation. If the configured range does not subscribe
to the new restricted values, an ISSU function using previously accepted values will be
rejected until the TWAMP-Light reflector is shut down. [191657]
Tools dump • The tools>dump>service>vxlan>usage command has been deprecated. The

commands tools>dump>service>evpn>usage command contains the information that used to be in
the deprecated command, as well as new pieces of information.
Release 13.0.R3
13.0.R3.
VLL Services • The following command has been deprecated:

Commands tools>dump>epipe-map-to-network
and is replaced by:
tools>dump>epipe-map-access-to-egress-port
The new command has been enhanced with additional information.
Release 13.0.R2
Release 13.0.R1
13.0.R1.

System
Commands
System • The following LAG load balancing commands in the config>system context have been
Commands moved one level deeper in the CLI hierarchy in a new load-balancing CLI context:
− [no] l4-load-balancing
− [no] lsr-load-balancing {lbl-only | lbl-ip | ip-only | eth-encap-ip}
− [no] mc-enh-load-balancing
− [no] system-ip-load-balancing
− [no] service-id-lag-hashing

configure configure
system system
[no] l4-load-balancing load-balancing
[no] lsr-load-balancing {lbl-only|lbl- [no] l4-load-balancing
ip|ip-only|eth-encap-ip} [no] lsr-load-balancing {lbl-
[no] mc-enh-load-balancing only|lbl-ip|ip-only|eth-encap-ip}
[no] system-ip-load-balancing [no] mc-enh-load-balancing
[no] service-id-lag-hashing [no] system-ip-load-balancing
[no] service-id-lag-hashing
• Cron scripts have been generalized in order to share a common script control between cron
and the new Event Handling System (EHS) feature. The cron action CLI context and
commands have been renamed to script-policy and moved into a new
config>system>script-control CLI context along with the cron script CLI context. The
rest of the config>cron CLI context has been moved to the config>system>cron context.
Similar changes have been made for the show>cron and tools>perform>cron commands.
Some cron show routine output and log events have had minor textual adjustments to
generalize them for use with EHS.

configure configure
cron system
cron
configure configure
cron system
action script-control
script-policy script-policy-name
configure configure
cron system
schedule cron
action schedule
script-policy script-policy-name
show show
cron system
cron
script-control
script
script-policy


clear clear
cron system
tod script-policy
cron
tod
tools tools
perform perform
cron system
script-policy
• The following PTP command has been renamed to align with the terminology used in the
ITU-T profiles:
config>system>ptp>peer>priority
and is changed to:
config>system>ptp>peer>local-priority
SNMP Commands • The following command has been renamed:

show system security communities
and is changed to:
show system security snmp community [community-name]
• The config>service>vprn>snmp-access and config>service>vprn>snmp-community
commands have been renamed as access and community, respectively, and have been
moved one level deeper in the CLI hierarchy in a new snmp CLI context.

configure configure
service service
vprn service-id vprn service-id
snmp-access snmp
snmp-community access
community
QoS
Commands
Network QoS • The command multicast-policer used to redirect traffic to an ingress FP queue group
Policy Commands within the ingress section of a network QoS policy has been deprecated and replaced by
mcast-policer. When a system is booted using Release 13.0 and the configuration contains
a multicast-policer statement configured within a FC in the ingress of a network QoS
policy, the command is automatically converted to mcast-policer and expanded to create

both a broadcast-policer and an unknown-policer referencing the same FP ingress queue

group policer.

configure configure
qos qos
network network-policy-id create network network-policy-id create
ingress ingress
fc name fc name
fp-redirect-group multicast- fp-redirect-group mcast-policer
policer policer-id policer-id
fp-redirect-group broadcast-
policer policer-id
fp-redirect-group unknown-policer
policer-id
A warning message is displayed, indicating that multicast-policer command is deprecated

and the new command is mcast-policer.
Note that the naming of the multicast-policer within the SAP ingress QoS policy remains
unchanged.
Router
Config
Commands
IP Router • The following LAG commands in the config>router>interface context have been moved
Commands one level deeper in the CLI hierarchy to include the load-balancing context:
− [no] egr-ip-load-balancing {source | destination}
− [no] teid-load-balancing

configure configure
router router
interface interface-name interface interface-name
[no] egr-ip-load-balancing load-balancing
{source|destination} [no] egr-ip-load-balancing
[no] lsr-load-balancing {lbl- {source|destination}
only|lbl-ip|ip-only|eth-encap-ip} [no] lsr-load-balancing {lbl-
[no] teid-load-balancing only|lbl-ip|ip-only|eth-encap-ip}
[no] teid-load-balancing
• The following command for resolution of a static route prefix using tunnels to an indirect
next-hop has been deprecated:
config>router>static-route {ip-prefix | prefix-length | ip-prefix netmask} indirect ip-
address {ldp| rsvp-te}[disallow-igp]

and is replaced by:

config>router>static-route-entry {ip-prefix | prefix-length} indirect {ip-address}
tunnel-next-hop
The new command is an add-on to the existing command to configure the resolution to tun-
nel next-hops. As such, when upgrading to Release 13.0, a static route resolved to an indi-
rect next-hop using the ldp or rsvp-te values will be converted into a couple of
configuration lines as shown in the table below. The existing static-route command under
VPRN will continue to be supported in Release 13.0 and does not allow resolving to tun-
nels.

configure configure
router router
static-route {ip-prefix|prefix- static-route {ip-prefic|prefix-
length|ip-prefix netmask} lengthI|Iip-prefix netmask}
indirect {ip-address} {ldp|rsvp- indirect ip-address
te}[disallow-igp] static-route-entry {ip-prefix|prefix-
length|ip-prefix netmask}
indirect {ip-address}
tunnel-next-hop
[no] disallow-igp
resolution {disabled|any|filter}
resolution-filter
[no] ldp
[no] rsvp-te
Cflowd • The command to enable sampling under IP interfaces has been changed to accommodate
Commands options for sampling both unicast and multicast independently. The previous Cflowd
command under the IP interface context:
cflowd {acl | interface} [direction {ingress-only|egress-only|both}]
has been replaced with the following command within a new CLI context named cflowd-
parameters:
sampling {unicast | multicast} type {acl | interface} [direction {ingress-
only|egress-only|both}]
The sampling command can be issued independently to enable and control the sampling of
unicast and multicast traffic. Upon upgrade to Release 13.0, any existing Cflowd configura-
tion commands under IP interfaces in the Base-routing context or IP services (IES or
VPRNs) will be automatically converted to the new CLI syntax for unicast. Administrators
can then add an additional sampling command to enable multicast sampling.

configure configure
router router
interface interface-name interface interface-name
cflowd {acl|interface} [direction cflowd-parameters
{ingress-only|egress-only|both}] sampling {unicast|multicast} type
{acl|interface} [direction
{ingress-only|egress-only|both}]

Routing
Protocols
Commands
IS-IS Commands • In Release 13.0.R1, the suppress-default command is changed to ignore-attached-bit.

The following table displays changes in the config>router context; similar changes the
suppress-default command to also apply to the config>service>vprn context.

configure configure
router router
isis isis
suppress-default ignore-attached-bit
BGP Commands • The command for resolution of a BGP prefix using tunnels to a BGP next-hop (BGP
shortcut) has been deprecated:
config>router>bgp>igp-shortcut {ldp|rsvp-te|mpls|mpls-bgp}[disallow-igp]
and is replaced by:
config>router>bgp>next-hop-resolution>shortcut-tunnel
When upgrading to Release 13.0, the following values in the configuration file are con-
verted as follows:

configure configure
router router
bgp bgp
igp-shortcut ldp next-hop-resolution
shortcut tunnel
family ipv4
resolution filter
resolution-filter ldp
... ...
igp-shortcut rsvp-te resolution filter
resolution-filter rsvp
... ...
igp-shortcut mpls resolution filter
resolution-filter ldp rsvp
... ...
igp-shortcut mpls-bgp resolution filter
resolution-filter bgp ldp rsvp
− The command for resolution of RFC 3107 BGP label route prefix using tunnels to a
BGP next-hop has been deprecated:
config>router>bgp>transport-tunnel {ldp|rsvp-te|mpls}
and is replaced by:
config>router>bgp>next-hop-resolution>label-route-transport-tunnel

When upgrading to Release 13.0, the following values in the configuration file are con-
verted as follows:

configure configure
router router
bgp bgp
no transport-tunnel next-hop-resolution
label-route-transport-tunnel
family ipv4
resolution filter
family vpn
resolution filter
... ...
transport-tunnel ldp family ipv4
resolution filter
family vpn
resolution filter
... ...
transport-tunnel rsvp-te family ipv4
resolution filter
family vpn
resolution filter
... ...
transport-tunnel mpls family ipv4
resolution filter
family vpn
resolution filter
MPLS
Commands
MPLS Commands • The following command has been deprecated:

config>router>mpls-labels>static-labels max-lsp-labels max-lsp-labels max-svc-
labels max-svc-labels
and is replaced by:
config>router>mpls-labels>static-label-range static-range
The static LSP and service label ranges are now collapsed into a single range usable by all
applications requiring a static label. During the upgrade to Release 13.0, the configuration
file is updated to reflect the new single static-label-range CLI with a range size matching
the value saved previously under the max-svc-labels parameter.
LDP Commands • With the introduction of LDP IPv6 in Release 13.0.R1, the LDP CLI has undergone major
changes. There are new commands, updates to existing commands, and deprecations of

commands. Changes to the CLI hierarchy also impact the configuration of LDP IPv4 peers
and targeted sessions. The following is a summary of the major changes. Numbered
explanations follow the table.

configure configure
router router
1 ldp ldp
peer-parameters session-parameters
peer ip-address peer ip-address
... ...
ldp ldp
2 peer-parameters tcp-session-parameters
peer ip-address peer-transport ip-address
... ...
ldp ldp
3 interface-parameters interface-parameters
ipv4
ipv6
... ...
ldp ldp
interface-parameters interface-parameters
4 interface ip-int-name interface ip-int-name [dual-
stack]
ipv4
ipv6
... ...
ldp ldp
interface ip-int-name interface ip-int-name [dual-
stack]
... ...
ldp ldp
interface ip-int-name interface ip-int-name
bfd-enable bfd-enable [ipv4][ipv6]
... ...
ldp ldp
7 targeted-session targeted-session
ipv4
ipv6
... ...
ldp ldp
interface-parameters interface-parameters
8 interface ip-int-name interface ip-int-name
multicast-traffic {enable|dis- ipv4
able} fec-type-capability
p2mp-ipv4 {enable|disable}
... ...
9 ldp-shortcut ldp-shortcut [ipv4|ipv6]
1. This change is made to better convey the scope of applicability of the commands which
apply to the LDP IPv4 or IPv6 session to a peer discovered over a link or to a targeted
peer. Only commands which apply to the LSR-ID are added to this scope. These com-
mands include per-peer FEC import and export policies and the label distribution mode
(DoD or DU).

2. This change is made to better convey the scope of applicability of the commands which
apply to the transport address; that is, the address of the TCP connection, which is not
always the address corresponding to the LDP LSR-ID. These are the authentication,
TTL security and path-MTU discovery commands.
3. The user can now configure different default parameters for IPv4 and IPv6 LDP inter-
faces.
4. The user can now configure different parameters specific to a given IPv4 or IPv6 LDP
interface. Note that there is a single instance of the bfd-enable option under the inter-
face context.
The shutdown command exists under the main interface context and under each of the
interface IPv4 and IPv6 contexts.
− The shutdown command under the interface context brings down both IPv4 and
IPv6 Hello adjacencies and stops Hello transmission in both contexts.
− The shutdown command under the interface IPv4 or IPv6 contexts brings down
the Hello adjacency and stops Hello transmission in that context only.
The user can also delete the entire IPv4 or IPv6 context under the interface with the no
ipv4 or no ipv6 commands, which, in addition to bringing down the Hello adjacency,
will delete the configuration.
5. The dual-stack optional keyword is introduced to distinguish between the configura-
tion file executions of prior releases from that in Release 13.0, as the interface node
implementation has changed in Release 13.0 to include new IPv4 and IPv6 contexts.
The key points of the new implementation are:
− If the keyword is provided, then IPv4 interface context will not be created. If it is
not provided, the IPv4 interface context will be created. This will take care of
executions of prior to Release 13.0 configurations on a router running a Release
13.0 image.
− This new keyword will always show in a Release 13.0 configuration.
− When entering an already configured interface, there is no need to provide the
keyword, but it will be ignored if provided.
When deleting a configured interface, the keyword will not be accepted in the no ver-
sion of the interface command.
6. The ipv4 and ipv6 keywords are optional keywords; if no keyword is chosen, then ipv4
is assumed to be enabled for backward compatibility.
The operation of BFD over an LDP interface is enhanced such that it tracks the next-
hop of prefix IPv4 and prefix IPv6 in addition to its tracking of the LDP peer IPv4/IPv6
address of the Hello adjacency over that link.
7. The user can now configure different default parameters for IPv4 and IPv6 LDP tar-
geted Hello adjacencies.
8. The enabling or disabling of the resolution of mLDP P2MP FEC over an interface is
replaced with the Hello adjacency FEC type capability. The latter improves the original
behavior by adding negotiation of the P2MP FEC type capability with the peer for each
interface and the ability to separately enable or disable mLDP IPv4 FEC and IPv6 FEC
types.
9. The ipv4 and ipv6 keywords are optional keywords; if no keyword is chosen, then ipv4
is assumed to be enabled for backward compatibility.

The user can now enable LDP shortcuts separately for IGP IPv4 and IPv6 prefixes. This
CLI command has the following behaviors:
− When executing a pre-Release 13.0 configuration file, the existing command is
converted as follows:
config>router>ldp-shortcut changed to config>router>ldp-shortcut ipv4
− If the user enters the command without the optional arguments in the Release
13.0 CLI, it defaults to enabling shortcuts for IPv4 IGP prefixes:
config>router>ldp-shortcut changed to config>router>ldp-shortcut ipv4
− When the user enters both IPv4 and IPv6 arguments in the Release 13.0 CLI,
shortcuts for both IPv4 and IPv6 prefixes are enabled:
config>router>ldp-shortcut ipv4 ipv6
• The following table details the changes to the syntax of the show commands to better
convey the scope of applicability of the command. Numbered explanations follow the
table.

show show
router router
1 ldp ldp
peer targ-peer
... ...
2 ldp ldp
peer-parameters session-parameters
... ...
3 ldp ldp
peer-template targ-peer-template
... ...
4 ldp ldp
peer-template-map targ-peer-template-map
... ...
ldp ldp
5
auth-keychain tcp-session-parameters [keychain
keychain]
... ...
ldp ldp
bindings bindings
6
prefix ip-prefix/ip-prefix-length prefixes
prefix ip-prefix|ip-prefix-
length
... ...
ldp ldp
bindings bindings
7 active active
prefixes
prefix ip-prefix|ip-prefix-
length
... ...
8 ldp ldp
status statistics
... ...
9 ldp ldp
bindings bindings [ipv4|ipv6]

1. Command shows parameters configured under config>router>ldp>targ-session>peer

x.y.z.w.
2. Command shows parameters configured under config>router>ldp>session-parame-
ters>peer x.y.z.w.
3. Command shows parameters configured under config>router>ldp>targ-session peer-
template.
4. Command shows parameters configured under config>router>ldp>targ-ses-
sion>peer-template-map.
5. The output of the show router ldp auth-keychain command can now be displayed
using show router ldp tcp-session-parameters [keychain keychain]
6. The show router ldp bindings prefix command has been moved one level deeper in
the CLI hierarchy in a new prefixes CLI context.
7. A new prefixes level in the CLI hierarchy has been added to the show router ldp
binding context to display the unicast IPv4/IPv6 FECs.
8. Some commands related to statistics, previously displayed under the show router ldp
status context, have now been moved to the new show router ldp statistics context.
9. The ipv4 and ipv6 keywords are a new subcontext to this command, so that the user
can specify the family in this context, rather than for each command in a deeper level in
the CLI hierarchy.
• The following changes to the syntax of the clear and debug commands were made to better
convey the scope of the applicability of the command. Numbered explanations follow the
table.

clear clear
router router
1 ldp ldp
instance instance family [ipv4|ipv6]
... ...
ldp ldp
2
interface ip-int-name interface ip-int-name [family
[ipv4|ipv6]]
debug debug
router router
3 ldp ldp
interface interface-name interface interface-name {family
{ipv4|ipv6}}
1. The ipv4 and ipv6 keywords are optional keywords; if no keyword is chosen, both ipv4
and ipv6 states are cleared.
2. The ipv4 and ipv6 keywords are optional keywords; if no keyword is chosen, both ipv4
and ipv6 states are cleared.
3. The ipv4 and ipv6 keywords are mandatory.

Layer-2
Services
Commands
VLL Services • The per-service-hashing command in the config>service>epipe context has been moved
Commands one level deeper in the CLI hierarchy to include the load-balancing context. The old
command will still be accepted if it comes from a configuration file but will not be
available in interactive CLI. There is no change from SNMP/MIB.

configure configure
service service
epipe service-id epipe service-id
per-service-hashing load-balancing
per-service-hashing
VPLS Services • The following command has been deprecated:

Commands config>service>vpls>allow-ip-int-binding
and is replaced by:
config>service>vpls>allow-ip-int-bind.
The latter is a CLI node, allowing the future addition of sub-commands below it.
• The per-service-hashing commands in the config>service>vpls and
config>service>template>vpls-template contexts have been moved one level deeper in
the CLI hierarchy to include the load-balancing context. The old command will still be
accepted if it comes from a configuration file but will not be available in interactive CLI.
There is no change from SNMP/MIB.

configure configure
service service
vpls service-id vpls service-id
per-service-hashing
... ...
template template
vpls-template name vpls-template name
per-service-hashing

Layer-3
Services
Commands
IES Commands • The following LAG commands in the config>service>ies>interface context have been
moved one level deeper in the CLI hierarchy to include the load-balancing context:

configure configure
service service
[no] teid-load-balancing {source|destination}
VPRN Services • The following LAG commands in the config>service>vprn>interface context have been
Commands moved one level deeper in the CLI hierarchy to include the load-balancing context:

configure configure
service service
[no] teid-load-balancing {source|destination}
• The following LAG commands in the config>service>vprn>network-interface context

have been moved one level deeper in the CLI hierarchy to include the load-balancing
context:


configure configure
service service
network-interface interface-name network-interface interface-name
[no] lsr-load-balancing {lbl- {source|destination}
only|lbl-ip|ip-only|eth-encap-ip} [no] lsr-load-balancing {lbl-
[no] teid-load-balancing only|lbl-ip|ip-only|eth-encap-
ip}
• The command for resolution of a VPN-IPv4 or VPN-IPv6 prefix to a BGP next-hop has
been renamed:
config>service>vprn>auto-bind {ldp|gre|rsvp-te|mpls|mpls-gre}
and is changed to
config>service>vprn>auto-bind-tunnel
When upgrading to Release 13.0, the following values in VPRN auto-bind in the configura-
tion file will be converted as follows:

configure configure
service service
auto-bind gre auto-bind-tunnel
resolution filter
resolution-filter gre
... ...
auto-bind ldp auto-bind-tunnel
resolution filter
... ...
auto-bind mpls auto-bind-tunnel
resolution filter
... ...
auto-bind mpls-gre auto-bind-tunnel
resolution filter
resolution-filter gre ldp rsvp
... ...
auto-bind rsvp-te auto-bind-tunnel
resolution filter
resolution-filter rsvp-te

Subscriber
Management
Commands
Subscriber • In Release 13.0.R1, the relay-unicast-msg CLI command has been renamed to relay-
Management proxy. The conversion from relay-unicast-msg to relay-proxy is done transparently so
DHCP Commands configurations saved in releases prior to Release 13.0.R1 can still be executed without
problem. There are no changes to the MIB field names.
A comparison of syntax prior to Release 13.0.R1 and in Release 13.0.R1 is as follows:

configure configure
service service
dhcp dhcp
relay-unicast-msg [release- relay-proxy [release-update-src-
update-src-ip] ip] [siaddr-override ip-address]
no relay-unicast-msg no relay-proxy
... ...
dhcp dhcp
update-src-ip] ip] [siaddr-override ip-
no relay-unicast-msg address]
no relay-proxy
configure configure
service service
dhcp dhcp
... ...
dhcp dhcp
... ...
dhcp dhcp
update-src-ip] ip] [siaddr-override ip-
no relay-unicast-msg address]
no relay-proxy

Subscriber • In Release 13.0.R1, the host-limit command has been deprecated and replaced with host-
Management limits overall and remove-oldest.
Commands

configure configure
subscriber-mgmt subscriber-mgmt
sla-profile sla-profile-name [create] sla-profile sla-profile-name [create]
host-limit max-number-of-hosts host-limits
[remove-oldest] overall max-nr-of-hosts
[no] remove-oldest
MS-ISA/
MS-ISA2
Application
Commands
Application • The following command has been deprecated:

Assurance mirror-dest isa-aa-group
Commands
• In Release 13.0.R1, the following commands have been changed. Numbered explanations
follow the table.

configure configure
application-assurance application-assurance
group aa-group id:partition-id group aa-group id:partition-id
url-filter-name url-filter-name
1
icap-http-redirect http-redirect
icap
server
vlan-id
configure configure
application-assurance application-assurance
group aa-group id:partition-id group aa-group id:partition-id
statistics statistics
2
aa-sub aa-sub
aggregate-stats aggregate-stats
export-using accounting-pol-
icy
show tools
application-assurance dump
group aa-group id:partition-id application-assurance
3 aa-sub-list group aa-group id:partition-id
policers-exceeded aa-sub-list [filter-by-type sub-
type] [isa mda-id]
policers-exceeded
1. With the introduction of local-filtering in the url-filter policy, the icap-http-redirect

command is renamed http-redirect, and both server and vlan-id are moved to the icap
context of the url-filter

2. The following command:

statistics aa-sub aggregate-stats
is replaced by:
statistics aa-sub aggregate-stats export-using accounting-policy.
3. The following command has been deprecated:
show application-assurance group aa-sub-list policers-exceeded
and is replaced by:
tools dump application-assurance group aa-sub-list [filter-by-type sub-type]
[isa mda-id] policers-exceeded
OAM
Commands
Diagnostics • As of Release 13.0.R1, legacy and Alcatel-Lucent-specific OAM commands no longer

Commands support the send-control option. Operators should stop using the send-control option with
the following OAM functions for both interactive CLI, SNMP and SAA:
− cpe-ping
− mac-ping
− mac-populate
− mac-purge
− mac-trace
With Release 13.0.R1, the send-control option will no longer be available. All SAA tests
that include this option will fail to start as of Release 13.0.R1. This option must be removed
from the SAA tests.
Tools Commands • The SAP and MPLS binding loopback with MAC swap commands in the tools>perform>
service>id>loopback>sap and tools>perform>service>id>loopback>sdp contexts have
been moved one level deeper in the CLI hierarchy under the eth context to more accurately
represent the Ethernet loopback function.

tools tools
perform perform
service service
id service-id id service-id
loopback loopback
sap eth
sap
... ...
loopback loopback
sdp eth
sdp

Usage Notes
Usage Notes
The following information supplements or clarifies information in the manuals for Release
13.0.R10 of SR OS.
XCM and SFM • In a 7950 XRS system, at least one SFM must be fully operational in order for the XCMs,
Recovery XMAs and standby CPM to be in service. If there are no operating SFMs in the system,
Behavior then the XCMs, XMAs and standby CPM will be held in a “booting” operational state.
• In a 7950 XRS system, at least one C-XMA/XMA in an XCM must be fully operational for
the XCM to be in service. If there are no operating C-XMAs/XMAs in an XCM, then the
XCM will be held in a “booting” operational state.
7750 SR-12e • For optimal performance, Alcatel-Lucent recommends that up to four (4) FP2-based
IOMs/IMMs for the 7750 SR-12e are installed in up to four (4) consecutive slots (for
example, slots 1-4 or 2-5).
7450 ESS-7/12 and • Specific engineering rules may apply when mixing FP2- and FP3-based line cards; contact
7750 SR-7/12/12e your Alcatel-Lucent representative for further details.
Multiservice The following tables list IOM and IMM support for MS-ISA/MS-ISA2 applications:
Integrated
Services Adapter Table 30. Compatible 7750 SR IOMs and IMMs for MS-ISA/MS-ISA2 Applications
(MS-ISA/MS-ISA2)
MS-ISM/MS-ISA2 IMM
MS-ISA2-E on IOM4-e
MS-ISA2-E on IOM-e
MS-ISA2 on IOM4-e
MS-ISA2 on IOM-e
IOM3-XP/-b/-c
IOM-20g-b
MS-ISM-E
IOM2-20g
Application Assurance ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
(isa-aa/isa2-aa)1,2
Retransmission and Fast Channel ✓ ✓ ✓

Change (isa-video)
Video Quality Monitoring ✓ ✓ ✓

(isa-video)
Video Dual Stream Selection ✓ ✓ ✓

(isa-video)
Local/Zoned Ad Insertion ✓ ✓ ✓
(isa-video)

Usage Notes
Table 30. Compatible 7750 SR IOMs and IMMs for MS-ISA/MS-ISA2 Applications
MS-ISM/MS-ISA2 IMM
MS-ISA2-E on IOM4-e
MS-ISA2-E on IOM-e
MS-ISA2 on IOM4-e
MS-ISA2 on IOM-e
IOM3-XP/-b/-c
IOM-20g-b
MS-ISM-E
IOM2-20g
Tunnel Services, including IPsec ✓3 ✓3 ✓ ✓
(isa-tunnel/isa2-tunnel)1
Network Address Translation ✓ ✓ ✓ ✓ ✓ ✓ ✓

(isa-bb/isa2-bb)1
L2TP LNS Service ✓ ✓ ✓ ✓ ✓

(isa-bb/isa2-bb)
WLAN-GW (isa-bb/isa2-bb) ✓ ✓4 ✓5 ✓6 ✓6
Arbor TMS (isa-tms) ✓
1. Application Assurance, Tunnel and IPsec services and NAT are also supported on the 7750
SR-c12.
2. Application Assurance is also supported on the 7750 SR-c4.
3. MS-ISA only. Not supported on MS-ISA-E.
4. MS-ISM only. Not supported on IMM.with a single MS-ISA2.
5. MS-ISM-E only. Not supported on IMM with a single MS-ISA2-E.
6. Requires both MDA slots in the IOM4-e to be equipped with MS-ISA2 (-E) cards.
Table 31. Compatible 7450 ESS IOMs and IMMs for MS-ISA/MS-ISA2 Applications
MS-ISM/MS-ISA2 IMM
MS-ISA2-E on IOM4-e
MS-ISA2 on IOM4-e
MS-ISA2-E IMM
IOM3-XP/-b/-c
IOM-20g-b
MS-ISM-E
Application Assurance (isa- ✓ ✓ ✓ ✓ ✓ ✓

aa/isa2-aa)
Retransmission and Fast Channel

Change ✓ ✓
(isa-video)

Usage Notes
Table 32. Compatible 7450 ESS Mixed Mode IOMs and IMMs for MS-ISA/MS-ISA2
Applications
MS-ISM/MS-ISA2 IMM
MS-ISA2-E on IOM4-e
MS-ISA2 on IOM4-e
MS-ISA2-E IMM
IOM3-XP/-b/-c
MS-ISM-E
Application Assurance ✓ ✓ ✓ ✓ ✓
(isa-aa/isa2-aa)
Retransmission and Fast Channel

Change ✓
(isa-video)
Tunnel Services, including IPsec ✓1 ✓ ✓

(isa-tunnel/isa2-tunnel)
Network Address Translation ✓ ✓ ✓ ✓ ✓

(isa-bb/isa2-bb)
L2TP LNS Service ✓ ✓ ✓

(isa-bb/isa2-bb)
1. MS-ISA only. Not supported on MS-ISA-E.
Compact Flash • Only Alcatel-Lucent-sourced Compact Flash devices for the SR OS are supported.
Devices • In Release 13.0.R1 and higher, Alcatel-Lucent recommends that the compact flash in the
CF3 slot be at least 2 Gbytes. The extra compact flash space is intended to support
customers who may want to keep more than one copy of the software.
• Alcatel-Lucent recommends using cf1: or cf2: for event logs and dynamic data persistency.
HW/Platform • SFPs with bad checksums cause traps and log events. The port will be kept operationally
down with SFPs that fail to read or have invalid checksums. [62458]
• When a dual-rate SFP is connected to a GigE LX SFP, the auto-negotiation parameter must
be turned off in order to get a link. [67690]
• Replacing an MS-ISA with another MDA type (that is, non MS-ISA MDA type) requires
the IOM to be reset after the new MDA is installed and configured. The IOM reset is only
required for types IOM-20g-b and IOM2-20g; IOM3-XPs do not require any action. If the
IOM was not reset after replacing the MS-ISA, the IOM may reset in the future. For more
information, refer to TA 12-0058.
• The SR OS routers support qualified pluggable optic modules only. Refer to the current
Alcatel-Lucent price list for supported modules. Third-party optics are not supported.

Usage Notes
System • When creating a new log file on a Compact Flash disk card, the system will check the
amount of free disk space and the amount must be greater than or equal to the lesser of
5.2 MB or 10% of the Compact Flash disk capacity.
• SNMPv3 user authentication and privacy keys in the configure system security user user-
name snmp authentication command must be entered as maximum length strings.
[18314]
• Manual editing of SNMP persistent index files can cause errors in loading the
configuration file. Persistent index files should only be created by the system. [24327]
• Downgrading from chassis mode C to chassis mode B may require the removal of IPv6
addresses from the BOF configuration. [133960]
• When nodes are run in FIPS-140-2 mode (where only FIPS-140-2 algorithms are enabled
and allowed), Alcatel-Lucent recommends only enabling the FIPS-140-2 mode on newly
deployed nodes. Changing to FIPS-140-2 mode on live nodes should be avoided as there
may be conflicts with existing configurations that are not consistent when running the node
in FIPS-140-2 mode. Before enabling a pre-configured node to run in FIPS-140-2 mode,
ensure all configurations in the configuration file are devoid of conflicting configurations
that are not allowed in FIPS mode, such as the use of any unapproved cryptographic
algorithms or certificates that are signed with unapproved algorithms. Refer to the Basic
System Configuration Guide for details.
SONET/SDH • The show port command on a SONET/SDH interface will only display the bottom 4 bits of
the S1 byte but will incorrectly display the bits as an entire byte. [17364]
ATM • 7750 SR and 7450 ESS in mixed mode allow configuration of user traffic on reserved ATM
Forum UNI specification VCI values (VCIs from 0 to 31 inclusive). Alcatel-Lucent
recommends not configuring any user traffic on those VCIs on any VP as other equipment
may treat that traffic per the defined usage reserved to a given VCI value. Additionally,
users must not configure VCIs 0, 3, 4, 6, and 7 on any VPI for services on ASAP MDAs, as
those VCIs are exclusively used for their ATM Forum defined and reserved functionality.
[53205]
MLPPP • When a MLPPP bundle is out of service (oos), the Oper MTU and Oper MRRU are derived
from the configured MRRU.
• Currently, LCP echo ids from 0–255 are separated into two ranges:
− 0–127 is used for keepalive function
− 128–255 is used for differential delay detection.
Keepalive statistics only count echo packets with IDs from 0-127.
• In order to interoperate with other vendors’ MLPPP implementations, the MLPPP sub-
layer will accept packets with or without leading zeros in the protocol field even though the
7750 SR and 7450 ESS in mixed mode do not advertise the protocol field compression
(PFC) option during LCP negotiation. [25996, 29923]
APS • Alcatel-Lucent recommends that the lb2er-sd and lb2er-sf alarms be enabled for
SONET/SDH ports belonging to APS groups to better understand some APS group
switchovers between the working and protect circuits.

Usage Notes
• For SONET/SDH ports belonging to APS groups that have a very large difference in the
transmission delay between the working and protect circuits, Alcatel-Lucent recommends
that the hold down timers be increased from their default values.
• Increased APS group scaling (above 32 MC-APS and 64 SC-APS) requires CPM3 or
higher for optimal switchover performance during failures affecting multiple groups.
Alcatel-Lucent recommends CPM3 or higher for APS group scaling over 64 groups.
TCP • Keychains with no active entries will keep LDP and BGP peerings down. [57917]
Authentication
Extension
Routing • Alcatel-Lucent recommends that the preference value for BGP routes be set to a higher
value than that of the internal (IGP) routes used to resolve the next-hop addresses of iBGP
routes or routing instability can occur while the BGP routes are constantly re-learned.
[31146]
Disallowed IP • The following IP address prefixes are not allowed by the unicast routing protocols and the
Prefixes Route Table Manager and will not be populated within the forwarding table:
− 0.0.0.0/8 or longer
− 127.0.0.0/8 or longer
− 224.0.0.0/4 or longer (used for multicast only)
− 240.0.0.0/4 or longer
Any other prefixes that need to be filtered can be filtered explicitly using route policies.
IS-IS • The granularity of the IS-IS hold timer is accurate only to within +/- 0.5s, so having a
computed holdtime value of less than 2s may result in adjacencies being randomly
dropped. Alcatel-Lucent recommends that hello-intervals and hello-multiplier values be
adjusted accordingly, paying specific attention to the smaller hold-times computed on DIS
systems. [29490]
• IS-IS authentication is not activated at any given level or interface unless both the
authentication key and type are added at that level. For instance, if hello-authentication-
type is set to password for an interface, it is not activated until a key is added at the
interface level. [34256]
IS-IS TE • The protocol sends advertisements with the IS-IS Traffic Engineering (TE) Router ID TLV
when traffic engineering is disabled. [17683]
Auto-derived • In a VPLS service, multiple BGP families and protocols can be enabled at the same time.
Route- When bgp-evpn is enabled, bgp-ad and bgp-mh are also supported. It is important to note
Distinguisher (RD) that a single RD is used per service and not per BGP family/protocol. The following rules
in services with apply.
multiple BGP − The VPLS RD is selected based on the following precedence:
families
− manual-RD or auto-RD always take precedence when configured

Usage Notes
− if there is no manual-RD/auto-rd configuration, the RD is derived from the bgp-

ad>vpls-id
− if there is no manual-RD/auto-rd/vpls-id configuration, the RD is derived from
the bgp-evpn>evi.
− if there is no manual-RDauto-rd/vpls-id/evi configuration, there is no RD, and
thus the service will fail
− The selected RD (see above rules) will be shown in the “Oper Route Dist” field of the
show service id bgp command.
− The service supports RD changes dynamically; for instance, the CLI allows the vpls-
id to be changed even while it is being used to auto-derive the service RD for bgp-ad,
bgp-vpls or bgp-mh. Note that, when the RD changes, the active routes for that
VPLS will be withdrawn and re-advertised with the new RD.
− If one of the mechanisms to derive the RD for a given service is removed from the
configuration, the system will select a new RD based on the above rules. For
example, if the vpls-id is removed from the configuration, the routes will be
withdrawn, the new RD selected from the evi, and the routes re-advertised with the
new RD.
− Note that this de-configuration will fail if the new RD already exists in a different
VPLS or Epipe.
− Because the vpls-id takes precedence over the evi when deriving the RD
automatically, adding evpn to an existing bgp-ad service will not impact the existing
RD—this is important to support bgp-ad to evpn migration.
BGP • Alcatel-Lucent recommends that the local address be configured when a router has
multiple BGP peers to the same node. [113614]
• The static blackhole route should be created prior to receiving routes or creating the policy
in combination with autobind GRE. [160617]
BGP Auto- • On the 7450 ESS without mixed mode, only the L2-VPN address family is supported by
Discovery BGP. This address family is used for BGP Auto-discovery for VPLS. Any commands or
options for other address families in BGP or in routing policies are not supported on the
7450 ESS except in mixed mode.
BGP VPWS • When a provisioned SDP that is used for a spoke-SDP is shut down, or there is a local LSP
failure (causing the spoke-SDP to go down), a BGP-VPWS update will be sent to the
adjacent PE with the CSV bit set to one (1). This, however, does not cause the spoke-SDP,
site or SAP to go down on the adjacent PE. If the adjacent PE is the designated forwarder
of a pair of dual-homed PEs, no designated forwarder failover occurs. The above situation
can result in the designated forwarder being one of the dual-homed PEs but the remote PE
using its pseudowire to the other dual-homed PE.
MPLS/RSVP • The current bypass binding selection logic for Release 7.0 and higher is the following:
− For non-strict environment
a) Manual CSPF disjoint bypass

Usage Notes
b) Manual CSPF !disjoint bypass

c) Dynamic CSPF disjoint bypass
d) Dynamic CSPF !disjoint bypass
− For strict environment
a) Manual CSPF disjoint bypass
b) Dynamic CSPF disjoint bypass
The above binding order has two (2) collateral/detrimental effects when the non-strict
option is selected:
1. In presence of a disjoint Dynamic Bypass, a non-disjoint Manual Bypass may be
selected instead.
2. Non-CSPF Manual Bypass will never be selected. [66005]
• The enabling or disabling of Diff-Serv on the system requires that the RSVP and MPLS
protocols be shut down. When first created in Release 7.0 or higher, RSVP and MPLS will
be administratively down. The user must execute the no shutdown command for each
protocol once all parameters under both protocols are defined. When saved in the
configuration file, the no shutdown command is automatically inserted under both
protocols to ensure they come up after a node reboot. In addition, the saved configuration
file is organized so that all LSP-level and LSP path-level configuration parameters are
executed after all MPLS and RSVP global- and interface-level parameters are executed.
• LSP MTU negotiation for P2MP LSP is not supported. End-to-end MTU along the S2L
path needs to be large enough to support data traffic. [74835]
LDP • On LDP interfaces and targeted-session keepalive commands, Alcatel-Lucent

recommends that the factor setting be set to a value greater than 1 or it may lead to
unexpected drops in LDP peerings. [67153]
• When a per-peer import/export policy, which is either non-existing, incorrectly configured
or not committed yet is configured, it may result in the system rejecting any FEC from
being imported/exported. The workaround is to ensure that the configuration files do not
contain policy mis-configurations or mismatches between LDP and the policy manager.
IP Multicast • If an rp static-address is configured, the current PIM implementation will install an

implicit deny-all for 224.0.0.0/4. To re-permit this address range, another static entry for
this range must be installed. [38630]
• MoFRR for PIM interfaces should be enabled on a hop-by-hop basis to ensure optimal
MoFRR recovery.
• If auto-rebalancing is enabled, re-balancing when a new path becomes available is
performed for active joins.
• Optimized IP-multicast replication over RSVP-TE spoke-SDPs using configurable
multicast network domains requires all spoke interfaces to be configured exclusively on
physical ports, LAG ports, or APS-protected ports. If that is not the case, the default
replication will take place.
• To execute mtrace and mstat with protocol-protection enabled (config>security>cpu-
protection), IGMP must be enabled on incoming interfaces. [160402]

Usage Notes
PIM • To ensure proper GRT/VRF extranet functionality, it is strongly recommend to shut down
PIM inside the VPRN (config>service>vprn>pim>shutdown) when enabling grt-
extranet functionality in this VPRN under the following cases:
− enabling grt-extranet for the first time in the VPRN
− configuring grt-extranet group-prefix any or grt-extranet group-prefix
224.0.0.0/4
− configuring grt-extranet group-prefix for a group that is already present in the
VPRN.
To ensure proper per-group map extranet functionality, it is strongly recommend to shut
down PIM inside the receiver VPRN (config>service>vprn>pim>shutdown) when
enabling the per-group mapping extranet functionality in this VPRN under the following
cases:
− enabling per-group mapping for the first time in the VPRN (that is, configuring the
first map entry)
− configuring group-prefix 224.0.0.0/4 inside the map (that is, mapping all multicast
groups to one core instance). [186280]
QoS • By default, the CBS value of newly-created queues in queue-group policies is zero (0)
percent. Adding queue-groups or other configuration may result in reservation of all
available buffer space (CBS) so that there is no shared buffer space available and queues
with CBS of zero (0) percent will drop traffic. Expedited traffic for newly-created queues
in queue-group policies with default CBS of zero (0) percent may also be lost when there is
congestion of non-expedited traffic. To prevent the loss of traffic, Alcatel-Lucent
recommends that the CBS value be changed to at least one (1) percent for expedited and
non-expedited queues, or for non-expedited queues, to ensure that shared buffer space is
available. Buffer memory can be monitored with the show pools command. [86843]
• On the SR-a4/a8, ingress multipoint traffic is forwarded using shared queuing instead of
the multipoint shared queuing. Specifically, the first pass through the FP uses the regular
service queues and the second pass uses the default shared unicast queues instead of the
default shared multipoint queues. Consequently, any parameter changes (for example, rates
and MBS/CBS) applied to the default shared multipoint queues will not have any effect on
the received multipoint traffic. [184678]
• profile-mode queues in FP3 platforms use two (2) offered statistic counters as opposed to
four (4) in non-FP3 platforms. This means FP3 unicast profile-mode queues provide
offered-uncolored and a combined in-/out- profile offered-colored statistics. FP3 multicast
profile-mode queues provide a combined offered-combined statistics and an offered-
mcast-managed statistics for managed multicast. Starting in Release 10.0.R1, multicast
profile-mode queues on non-FP3 platforms report offered-uncolored and offered-managed
using separate counters. No new MIB object is added as part of these statistics changes.
Since existing MIB objects are used, non-FP3 profile-mode multicast queue offered-
managed and offered-uncolored are accounted using the same MIB object. The show
command output displays offered-managed and offered-uncolored as separate statistics for
profile-mode non-FP3 multicast queues. The show command output also displays
different statistic counters based on platform type.

Usage Notes
Filter Policies • Starting with Release 11.0.R1, the maximum number of filter policies and filter policy
entries per system is larger than the line card limit. Since filter statistics are maintained on
line cards and aggregated on the CPM/CFM, when an entry is deleted from a given line
card (that is, an entry is deleted, or a given filter policy is no longer used on a given line
card), the CPM/CFM resets that entry’s counters to zero. If the counters are required, they
should be retrieved prior to such a configuration change.
• Alcatel-Lucent recommends against deploying the same filter policy on both ingress and
egress because ingress and egress filter policies support different functionalities (actions
and/or match criteria).
• Using a filter policy on a line card or in a direction that does not support a given match
criterion may result in an unexpected match by the filter entry. It is recommended to avoid
such configurations.
• When a filter policy is used on a line card that does not support a given action or in a
direction that does not support that action, the action is ignored; if the packet matches the
entry, default action is executed.
• Starting from Release 11.0.R1, all newly-introduced filter policy functionality is no longer
supported in combination with ToD functionality. Alcatel-Lucent recommends against
configuring a filter policy that has both ToD and Release 11.0.R1 or newer filter policy
enabled.
Services General • Starting in Release 10.0.R3, a PW port needs to be created first (with encap-type dot1q or
qinq) before it can be bound to the SDP. Configurations containing PW-port entries from
releases prior to Release 10.0.R3 are not compatible. [134086]
Proxy-ARP/ND When enabling Proxy-ARP/ND in a VPLS service, Alcatel-Lucent recommends the following
recommended configuration for the correct network behavior:
settings • Alcatel-Lucent recommends enabling dynamic-arp-populate or dynamic-nd-populate
only in networks with a consistent configuration of this command in all PEs. In EVPN
networks where some nodes do not support this feature, dynamic-arp-populate and
dynamic-nd-populate should only be enabled if the EVPN nodes always advertise IP-
>MAC pairs in MAC routes. For example, when an SR OS router is used as a Data Center
(DC) Gateway for a Nuage DC, the user should enable dynamic-arp-populate only if all
the Nuage Vports in the service are type host or VM (since their IPs will be advertised in
MAC routes).
• When using dynamic-arp-populate/dynamic-nd-populate, the age-time value should be
configured to a value equal to three times the send-refresh value. This will help reduce the
EVPN withdrawals and re-advertisements in the network.
• In case of large age-time values, it would be sufficient to configure the send-refresh value
to half of the proxy-ARP/ND age-time or FDB age-time.
• In scaled environments (with thousands of services) it is not recommended to set the send-
refresh value to less than 300 seconds. In such scenarios, Alcatel-Lucent recommends
using a minimum proxy-ARP/ND age-time and FDB age of 900 seconds.
• The use of the following commands reduces or suppresses the ARP/ND flooding in an
EVPN network, since EVPN MAC routes replace the function of the regular data plane
ARP/ND messages:
− no garp-flood-evpn

Usage Notes
− no unknown-arp-request-flood-evpn
− no unknown-ns-flood-evpn
− no host-unsolicited-na-flood-evpn
− no router-unsolicited-na-flood-evpn
Alcatel-Lucent recommends using these commands only in EVPN networks where the CEs
are routers directly connected to an SR OS node acting as the PE. Networks using aggrega-
tion switches between the host/routers and the PEs should flood GARP/ND messages in
EVPN to make sure the remote caches are updated and BGP does not miss the advertise-
ment of these entries.
• When the anti-spoof-mac is used with Proxy-ARP/ND, ingress filters (in the access
SAPs/SDP-bindings) should be configured to drop all traffic with destination anti-spoof-
mac. The same MAC should be configured in all PEs where dup-detect is active.
• When Proxy-ND is used, the configuration of the following commands should be
consistent in all the PEs in the network:
− router-unsolicited-na-flood-evpn
− host-unsolicited-na-flood-evpn
− evpn-nd-advertise
Since EVPN does not propagate the “router” flag in IPv6->MAC advertisements, in a
mixed network with hosts and routers, if evpn-nd-advertise router is configured, unsolic-
ited host NA messages should be flooded so that the entire network gets to learn all of the
host and router ND entries. In the same way, evpn-nd-advertise host should be configured
if unsolicited router NA messages are flooded.
Subscriber • Dynamic data persistency (subscriber management, DHCP server, Python-policy cache,
Management NAT port forwarding, Application Assurance or ANCP) usage notes are as follows.
− Alcatel-Lucent recommends discontinuing the use of 256M and 1G compact flash
cards for dynamic data persistency applications; using a 4G or 8G compact flash card
is recommended. From Release 13.0.R1 onwards, Alcatel-Lucent recommends using
an 8G compact flash card when enabling multiple dynamic data persistency
applications.
− Dynamic data persistency should not be configured to use compact flash cards
formatted with the Reliance file system.
− Alcatel-Lucent recommends a maximum of two (2) applications on the same compact
flash card when using multiple dynamic data persistency applications.
− CF3 must not be used as the location for dynamic data persistency.
− XML accounting (stored on compact flash) should not be used in conjunction with
dynamic data persistency. Alcatel-Lucent recommends RADIUS accounting as an
alternative. [50940]
• Starting with Release 11.0.R1, a RADIUS server configured under the routing instance
(base, management or VPRN service) radius-server context can be used for authentication
and accounting applications simultaneously. It is now possible to configure an auth-port
and an acct-port for each server. When upgrading from a release prior to Release 11.0.R1,
the single port configured for the server is automatically migrated to the new configuration.
In this case, both auth-port and acct-port will have the same value. This is not a problem

Usage Notes
for the active configuration, but needs to be manually updated if the server is used for
multiple applications.
• DHCPv6 server DUID configuration guidelines in multi-chassis redundancy scenarios are
as follows:
− In a redundant DHCPv6 server configuration, each server must have a unique DUID
(configured as server-id in the router | service vprn dhcp6 local-dhcp-server CLI
context). Configuring an identical DUID with failover mode local/remote can result
in unpredictable or multiple prefix allocation.
− In a multi-chassis redundant DHCPv6 proxy-server configuration, both proxy-servers
must share the same DUID (configured as server-id in the group-interface ipv6
dhcp6 proxy-server CLI context). Configuring a different DUID can result in
ignoring the lease renewal and release after an SRRP switchover.
Use of BGP-EVPN, • BGP-EVPN, BGP-AD and BGP-MH (one site) can all be configured in the same VPLS
BGP-AD and BGP- service. If that is the case, the following considerations apply:
MH in the same − The configured BGP route-distinguisher and route-target are used by BGP for the two
VPLS service families (that is, EVPN and L2-VPN). If different import/export route targets are used
per family, vsi-import/export policies must be used.
− The pw-template-binding command under BGP does not have any affect on EVPN
or BGP-MH. It is only used for the instantiation of the BGP-AD spoke-SDPs.
− If the same import/export route-targets are used in two (2) redundant systems for
BGP-EVPN and BGP-AD, a VXLAN binding, as well as a FEC129 spoke-SDP
binding, may be attempted between the two systems, creating a loop. If that is the
case, the SR OS will allow the establishment of an EVPN VXLAN binding and an
SDP-binding to the same far-end, but it will keep the SDP-binding operationally
down. Only the VXLAN binding will be operationally up. [170951]
VPRN/2547 • A route policy statement entry referencing a non-existent prefix list, community list, or AS
path list will be accepted without a warning when committing a route policy configuration.
This kind of missing reference can be seen when executing show router policy-edits.
[60879, 84264, 86129]
IPsec • IKE traffic should be treated as higher priority than any data plane traffic (like ESP) on the
end-to-end path from a remote IPsec peer to a 7750 SR, which means that appropriate
ingress/egress QoS policy should be configured on the corresponding network facing port
(or SAP) and public tunnel-SAP of 7750 SR and any other network forwarding node along
the way.
• CRL NUMBER is a non-critical CRL extension; the CRL file provisioned in ca-profile
should not mark this extension as critical.
• Certificate configured in cert-profile or by the cert command under ipsec-tunnel/ipsec-
gw should be an end-entity certificate; a CA certificate should not be configured in these
places.

Usage Notes
IPsec • The following tables list software and hardware tested for compatibility with IPsec
Compatibility services:
Table 33. Compatible Devices for dynamic LAN-to-LAN IPsec Tunnels
Device Tested Version

Alcatel-Lucent VPN Firewall Brick 1200 9.1
Bintec Funkwerk R1200WU 7.5 Rev 3
Table 34. Compatible IPsec Soft Client
Soft Client Tested Version(s)

Cisco VPN Client 5.0.03.0560
Racoon NetBSD running ipsec-tools 0.7
SafeNet SoftRemote 10.8.3
Shrewsoft 2.1.2
Strongswan 2.8.x, 4.2.x, 5.0.1
Time-of-Day • In a TOD suite, items can be defined that cannot be applied to all SAP types: for instance,
Suites an IP filter in the TOD suite that is then assigned as the TOD suite to a VPLS SAP. When
the IP filter becomes active, the system will detect that it is not possible to assign the suite
to the SAP and generate a log event.
• When a TOD suite is applied to a SAP, there may be conflicts that make it impossible to
install all of the current TOD suite defined values. The conflicts can be between the TOD
suite defined values or between SAP configured values and TOD suite defined values. A
log event is always generated when a conflict occurs. The possible conflicts are:
− An ingress MAC filter cannot be installed with an ingress IP filter, ingress IPv6 filter
or ingress QoS policy which has IPv6 criteria. The MAC filter will not be installed.
− An egress MAC filters cannot be installed with an egress IP filter or egress IPv6 filter.
The MAC filter will not be installed.
− An ingress IPv6 filter cannot be installed with an ingress QoS policy which has MAC
criteria. The filter will not be applied.
• At system boot, it is possible that the “intended value” (be it from the TOD suite or a
configured value) of a policy assignment cannot be applied due to resource unavailability;
at that time, there is no previous state to which to revert, and the SAP (or multi-service site
(MSS)) ends up with a default policy assignment. In this situation, the SAP (or all of the
MSS's SAPs) is (are) placed in an operationally down state with the appropriate flag set.
− “SapTodResourceUnavail” indicates that the SAP has a TOD suite and could neither
apply it nor revert to the previous state. The SAP will have a default policy
configured.
− “SapTodMssResourceUnavail” indicates that the SAP has a Multi-Service Site that
uses a TOD suite, and the MSS could neither apply the TOD suite nor revert to its
previous state. The SAP will have a default scheduler policies configured, i.e. none.
These flags get cleared whenever a subsequent application of the TOD suite is successful
and the intended policies can be configured.

Usage Notes
• When the QoS and scheduler policy assignment of a SAP or MSS is changed by action of
its TOD suite, packet loss may occur, just like when the configuration is modified directly
by CLI or SNMP.
• The number of assignments in a given TOD suite is implicitly limited to 100 (10 types of
parameters each with 10 possible priority values).
OpenFlow • H-OFS supports statistics collection per entry for Flow Table and Logical Port Table. Due
to large H-OFS scale, Alcatel-Lucent recommends that a single statistics request message
from the controller does not map (using a wildcard or cookie) to more than 1000 Flow
Table entries per cookie context per message or ten (10) Logical Port Table entries per
message.
Application • Operators using applications maintained by Alcatel-Lucent for analytics, charging, or

Assurance control should update both protocol signatures and the AA policy definition on a regular
basis. New and updated protocols are available in the isa-aa.tim file while the AA policy
update is provided through Alcatel-Lucent technical support. See AA Signatures Upgrade
Procedure for more details.
• The isa-aa.tim image is available in the same directory as other .tim images. The image
contains the Application Assurance software used on MS-ISA and the protocol list loaded
by the CPM. The Application Assurance software can be upgraded independently of the
SR OS software within a major release of the SR OS.
• When an Application-Assurance group dual-bucket-bandwidth policer is configured, the
default configuration will cause all packets to be dropped. Ensure that the dual-bucket-
bandwidth policer is configured appropriately. [86311]
• Only properly negotiated TCP sessions are eligible for TCP performance sampling.
• Changes to the TCP performance sampling rates will only affect new traffic flows.
• The bandwidth capacity for an AA-subscriber is equal to the full capacity of the MS-ISA or
MS-ISA2 card, provided there is a realistic diversity of traffic sessions. The bandwidth
capacity of an individual traffic session is limited by the in-order analysis and the amount
of high-touch processing required by each packet in the session.
• If a Forwarding Path (FP) is configured with one MDA type of ISA-AA and any other
MDA type (except a second ISA-AA) on an IOM3 or on a 7750 SR-c4/c12 system, then
the FP buffer allocation must be modified from the default values; otherwise, there may be
insufficient buffers for the non-ISA-AA MDA, which may lead to packet discards.
[117290]
• The use of AARP on multi-homed, active-active SAPs or spoke-SDPs will force some of
the traffic to use the inter-shelf AARP shunt interfaces. The AA remote divert will override
policy-based routing (such as for NAT forwarding) applied on filters for traffic from the
AARP instance (SAP or spoke-SDP).
• When detect-seen-ip is enabled in a transit-ip-policy, the operator must ensure that a
default app-profile is configured. If there is no default app-profile and an app-profile is
not provided by either RADIUS, Diameter or DHCP, then AA subscriber creation will fail;
however, traffic for that subscriber will continue to traverse the AA on the parent context.

Usage Notes
BFD • per-fp-egr-queuing for LAG-based SAPs that have BFD sessions should not be enabled.
When per-fp-egr-queuing is configured on a LAG and fast BFD is enabled for any SAP
interface on that LAG, the BFD packets may be dropped on egress during LAG physical or
logical port oversubscription. This condition may lead to the BFD session going down.
BFD on LSPs • Interoperability with non-SR OS implementations of LSP BFD is not supported in Release
13.0.R4.
BFD VCCV • The following table describes BFD VCCV interoperability with JunOS running on Juniper
MX. [185090]
Table 35. BFD VCCV Interoperability with Juniper MX
Service Interoperability
BGP-VPLS BFD VCCV inter-op not supported
LDP-VPLS BFD VCCV inter-op supported
Epipe control-word BFD VCCV inter-op supported
Epipe no-control-word Inter-op not supported
VPWS control-word Inter-op not supported
BGP-EVPN and • In general, the recommended version to be used with Release 13.0.R4 is Nuage 3.2.R1 and
XMPP higher for XMPP interoperability.
interoperability • The use of the “Policy-Based Forwarding/Routing to an EVPN ESI” feature, for the
with Nuage integration of the SR OS nodes in the Nuage Service Chaining architecture, requires
Release 3.2.R1 or higher in the Nuage VSC.
• The use of XMPP for the Fully-Dynamic VSD integration model requires Release 3.2.R1
or higher in the Nuage VSD. If lower VSD release versions are to be used, the following
compatibility matrix provides an indication of the combinations that work or do not work:
Table 36. Nuage VSD and SR OS Node XMPP Compatibility
Nuage VSD Release SR OS Release Compatibility Comments1

3.0.R3 – R5 12.0.R7 – R9 ✓ S-D only
13.0.R1 – R2 ✓ S-D only
12.0.R10 and higher X —
13.0.R3 and higher X —
3.1 Any X Not a DC version
3.0.R6 and higher 12.0.R7 – R9 X —
13.0.R1 – R2 X —
12.0.R10 and higher ✓ S-D only

Usage Notes
Table 36. Nuage VSD and SR OS Node XMPP Compatibility (Continued)
Nuage VSD Release SR OS Release Compatibility Comments1

3.2.R1 and higher 12.0.R7 – R9 X S-D only
13.0.R1 – R2 X S-D only
13.0.R3 ✓ S-D only
13.0.R4 and higher ✓ S-D and F-D
1. S-D = Static-Dynamic model, F-D = Fully-Dynamic model.
• A number of changes have been progressively introduced in the Nuage and SR OS EVPN-
VXLAN implementation in order to align the control plane with the relevant IETF
standards. In general, the use of SR OS Release 13.0.R4 and Nuage Release 3.2.R1 or
higher is recommended. If lower release versions are to be used, the following
compatibility matrix provides an indication of the combinations that work or do not work
for EVPN. Note that if VSD – SR OS node integration is required, the above table must
also be considered.
Table 37. Nuage VSP and SR OS Node EVPN Compatibility
Nuage Release SR OS Release Compatibility Comments

Up to 3.0.R3/3.1.R2 12.0.R7 ✓ —
12.0.R8/13.0.Rx X Incompatible extended
community values: RFC
5512 BGP encapsulation
and Router’s MAC.
3.0R4-R6/3.1.R3 12.0.R7 X Incompatible extended
community values: RFC
5512 BGP encapsulation
and Router’s MAC.
12.0.R8 and higher ✓ —
3.2.R1/3.0.R8 and higher 12.0.R7-R8 X Different VNI encoding
can create issues
13.0.R1 X Different VNI encoding
can create issues
• Notes: the following changes have been implemented along the releases:
− The standard EVPN extended community values were introduced in Nuage Release
3.0.R4/3.1.R3 and SR OS Release 12.0.R8. Before those releases:
− The VXLAN tunnel value in the RFC 5512 BGP encapsulation extended
community was not compliant with draft-ietf-bess-evpn-overlay.

Usage Notes
− The Router’s MAC extended community type/sub-type was not compliant with
draft-ietf-bess-evpn-prefix-advertisement.
− From SR OS Release 12.0.R9/13.0.R2 and higher, the label field is interpreted as a
24-bit value when the encapsulation is VXLAN and it is ignored. Up to these releases,
the SR OS node was expecting the Bottom of Stack (BoS) bit set in the label field.
− From Nuage Release 3.2.R1 on, Nuage encodes the VNI in both, the Ethernet Tag and
label fields. It can accept VNIs from both fields.
− From SR OS Release 13.0.R4 on, the SR OS node encodes the VNI in the label field.
It can accept VNIs from both fields.
− Note that support for AD routes (EVPN route type 1) on the SR OS node has been
introduced in SR OS Release 13.0.R4. Prior to that release, the SR OS node would
discard any AD route received from VSC.
− Nuage Release 3.0.R7 is not recommended in combined SR OS node and Nuage
EVPN deployments.

Software Upgrade Procedures

The following sections contain information for upgrading to the Release 13.0.R10 software
version.
− Software Upgrade Notes
Information on upgrading the router from previous versions of SR OS software
including rules for upgrading firmware and any special notes for upgrading from
specific earlier versions.
− AA Signatures Upgrade Procedure
Information on upgrading MS-ISA to a new AA-signature load.
− ISSU Upgrade Procedure
Procedure for performing an ISSU to Release 13.0.R10 including information on
applicability of ISSU for earlier versions.
− Standard Software Upgrade Procedure
Procedure for performing a standard, service-affecting upgrade including updating of
firmware images.
Software Upgrade Notes

The following sections describe notes for upgrading from prior versions of SR OS to 13.0.R10.
Notes:
• An admin reboot upgrade is required for all 7450 ESS-6 and ESS-6v chassis running Release 8.0
or an earlier major release, Release 9.0.R22 or an earlier 9.0 minor release, Release 10.0.R12 or an
earlier 10.0 minor release, or Release 11.0.R3 or an earlier 11.0 minor release.
• Automatic firmware updates may occur for CPM and IOM/IMM/XCM cards running older
firmware after a SR OS upgrade. The clear card command or physical removal of a card must not
be performed until the card is operationally up after an SR OS upgrade. This procedure also
applies when subsequently adding new IOMs/IMMs/XCMs (that may have older firmware) to a
chassis. An event log with “firmware upgraded” message will be issued if a firmware update had
occurred for a card.
The following conventions are used in configuration files:

• Deprecated commands are not flagged as errors upon reading a configuration file with
deprecated commands, but these commands will not be written to a saved configuration
file.
• Modified commands are read using the old format, but they are written out with the new
format in a configuration file; so a configuration file saved with modified commands is not
compatible with earlier releases.
• Modified parameters are supported when they are read, but the modified parameters will be
converted to new minimums or maximums when saved in a configuration file.

Upgrading to • Release 13.0.R10 changes the way XML Accounting files are formatted. Parsing functions
Release 13.0.R10 in operator OSS layers may need to be adjusted if they had custom logic to work around the
or Higher invalid SR OS XML formatting. Prior to Release 13.0.R10, the XML encoding used in
SR OS accounting files for certain special characters was invalid. As of Release 13.0.R10,
SR OS accounting files correctly encode the special characters as “<”, “>”, “&”,
“'”, and “"” instead of placing characters such as “<” directly into the
accounting files. OSS parsing logic for Release 13.0.R10 and higher XML Accounting
files must be able to handle the standard XML encoding for the special characters.
Upgrading from • When upgrading from Release 13.0.R5 to Release 13.0.R6 or higher, there is a mandatory
Release 13.0.R5 to firmware upgrade for all CPMs and IOMs on the 7750 SR-a4/a8.
13.0.R6 or Higher During the software upgrade, the cards that require new firmware will automatically update
their firmware when they are rebooted as part of the normal software upgrade process. The
firmware update will cause a longer reboot time than usual (approximately 10 minutes
instead of a few minutes). Ensure the cards are not removed while they are reprogramming
the firmware. The Operational State of a card that is reprogramming its firmware will be
displayed as “provisioned” under show card and the Equipped Type will be displayed as
“not equipped”. [208437, 216782, 217615]
Upgrading to • When upgrading to Release 13.0.R5 from a previous release, there is a mandatory firmware
Release 13.0.R5 or upgrade for certain cards and platforms:
Higher − 7750 SR-a4/a8: all CPMs and IOMs (note that ISSU is not supported on the
7750 SR-a platform)
− 7750 SR-7/12/12e: the CPM5 has new mandatory firmware in Release 13.0.R5 (this
does not affect ISSU—CPMs are always rebooted during ISSU)
During the software upgrade, the cards that require new firmware will automatically update
their firmware when they are rebooted as part of the normal software upgrade process
(ISSU or non-ISSU). The firmware update will cause a longer reboot time than usual
(approximately 10 minutes instead of a few minutes). Ensure the cards are not removed
while they are reprogramming the firmware. The Operational State of a card that is repro-
gramming its firmware will be displayed as “provisioned” under show card and the
Equipped Type will be displayed as “not equipped”.
13.0.R4 YANG • In Release 13.0.R4, the following changes were made to the YANG modules without
Modules retaining the old elements and marking them as obsolete or deprecated:
− In the alu-conf-filter-r13.yang file, the child leafs in the dhcp6-filter/default-action
container were reworked in Release 13.0.R4. The default-action-id leaf no longer
exists in the YANG file (no obsolete status).
− In the alu-conf-filter-r13.yang file the modeling of the “action” container for ip-filter
and ipv6-filter entries has changed in Release 13.0.R4. The drop, forward, http-
redirect and nat leafs have been changed to containers (to model a similar change in
CLI) and many leafs that existed at the “action” level are now underneath drop,
forward, http-redirect or nat. These changed drop, forward, http-redirect and nat
nodes have not changed names and the other moved leaves are not marked with
deprecated or obsolete status in the YANG file in their old locations in the tree.

− The alu-conf-svc-vpls-sap-r13.yang file changed the ascii-tuple and vlan-ascii-tuple

in the circuit-id container from leafs to enum values.
Subscriber • Due to increased memory requirements as a result of new software features, the maximum
Management subscriber-host scale is 128k per system for the 7750 SR-7/12, 7450 ESS-7/12 equipped
with CPM3, and operating in chassis mode D. This limit is not enforced by the system. For
existing deployments that need a higher subscriber-host scale and want to upgrade to
SR OS Release 13.0, it is recommended to install CPM5 to provide more memory capacity.
[199108]
Cflowd • In Release 12.0.R9, the new Cflowd command use-vrtr-if-index was introduced. If
upgrading from Release 12.0.R9 or later to Release 13.0.R1 or 13.0.R2, and this new
command has been enabled, or admin save detail was used to save the system’s
configuration, then all mention of this command must be removed from the saved
configuration file before attempting to upgrade to Release 13.0.R1 or 13.0.R2.
Upgrading to • Upgrading from a release earlier than Release 12.0.R2 to Release 13.0.R1 or higher can
Release 13.0.R1 or incorrectly change the configuration of nat outside pool redundancy to shutdown state.
Higher This configuration must be manually corrected. [215881-MA]
• With the introduction of LDP IPv6 in Release 13.0.R1, a FEC for each of the IPv4 and IPv6
system interface addresses is advertised and resolved automatically by the LDP peers when
the LDP session comes up, regardless of whether the session is IPv4 or IPv6.
To avoid the automatic advertisement and resolution of IPv6 system FEC when the LDP
session is IPv4, the following procedure must be followed before and after the upgrade to
the SR OS version which introduces the support of LDP IPv6.
1. Before the upgrade, implement a global import prefix policy which rejects prefix [::0/0
longer] to prevent IPv6 FECs from being installed after the upgrade.
2. In Major ISSU case:
− If new IPv4 sessions are created on the node, the per-peer FEC-capabilities must
be configured to filter out IPv6 FECs.
− Until an existing IPv4 session is operationally toggled, FEC-capabilities have no
effect on filtering out IPv6 FECs; thus, the global import policy must remain
configured in place until the session toggles. Alternatively, a per-peer-import-
policy [::0/0 longer] can be associated with this peer.
3. In cold upgrade case:
− If new IPv4 sessions are created on the node, the per-peer FEC-capabilities must
be configured to filter out IPv6 FECs.
− On older, pre-existing IPv4 sessions, the per-peer FEC-capabilities must be
configured to filter out IPv6 FECs.
4. When all LDP IPv4 sessions have dynamic capabilities enabled, with per-peer FEC-
capabilities for IPv6 FECs disabled, then the global import policy can be removed.
RMON • RMON entries that referenced deprecated MIB entries are not automatically modified and
re-saved with the MIB variable that may have replaced it. MIB variable changes are often
due to a change in the indexing structure for such tables. Refer to the MIBs distributed with

your SR OS image set and compare those as needed to MIBs from the prior SR OS release
to identify changes and update the corresponding SNMP object or OID references in the
configuration file.
MLD • The checks for a valid link local address are corrected for some cases.
The checks are stricter starting in Release 12.0.R4. Previously, addresses in the range of
FE80::/10 were accepted (for example, FE81:: was accepted). Now the check is corrected
and only addresses in the range of FE80::/64 are accepted.
This will have an impact when performing an upgrade: configured values not in the
FE80::/64 range will be rejected.
Impacted configuration commands are:
− config>router>mld>group-interface group-interface-name>query-src-ip link-local
address
− config>service>vprn service-id>group-interface group-interface-name>query-src-
ip link-local address
− config>router>mld>grp-if-query-src-ip link-local address
− config>service>vprn service-id>mld grp-if-query-src-ip link-local address
− config>router>interface interface-name>ipv6 link-local-address link-local-address
− config>service>vprn service-id>interface interface-name>ipv6 link-local-address
link-local-address [172857]
MPLS • Since Releases 10.0.R4 or 11.0.R1, when the system starts Major or Minor ISSU
Maintenance Mode procedures, MPLS will automatically be put into a maintenance mode such that existing
during ISSU or LSP paths will continue to operate normally while the node will not issue new LSP paths or
Soft Reset a Make-Before-Break (MBB) path for existing LSPs. It will also reject requests for new
LSP paths or MBB paths of existing LSPs coming from RSVP neighbors. The MPLS
module will automatically exit the new maintenance mode when the Major or Minor ISSU
is completed.
Upgrading to • A configuration with an IPv6 prefix present in the router>router-advertisement interface

Release 12.0.R1 or context on a non-mixed mode 7450 ESS will fail to execute from Release 12.0.R1 onward.
Higher It was possible in releases prior to Release 12.0.R1 to configure, although this was
functionally not supported. If such a configuration exists, it has to be removed prior to
upgrading to Release 12.0.R1 or later.
• The configuration command configure system security user user-name console login-
exec " " (single space URL) will fail to execute from Release 12.0.R1 onwards. Prior to
Release 12.0.R1, it was possible to issue this configuration command, although it contained
an invalid URL. If such a configuration exists, it must be removed/updated prior to
upgrading to Release 12.0.R1 or later.
DHCP • When upgrading from Release 10.0.R10 through 10.0.R15 or from Release 11.0.R1
through 11.0.R7 to Release 12.0.R1 or higher, and DHCPv6 server and/or DHCPv6 relay
on subscriber interfaces is/are enabled to assign IA_NA addresses, it may be required to
add the global configuration parameter adv-noaddrs-global esmrelay server under the
config> system>dhcp6 context for backward compatibility. This parameter will send the

“NoAddrsAvail” status code in DHCPv6 advertise messages at the global DHCP message
level instead of at the default IA_NA option level.
Routing Policies • From Release 12.0.R1 onwards, the use of a community, as-path, as-path-group or
prefix-list name starting and ending with '@' is no longer allowed. @...@ is used as
identification for parameters being used in policies. Upgrading from a pre-Release 12.0.R1
to Release 12.0.R1 or higher will mean that configuration files containing such names will
fail to execute. [173346]
MPLS/RSVP • The LFA SPF policy feature generalizes the use of admin-group and SRLG to non-MPLS
interfaces. To that end, the definition of admin-groups and SRLGs has been moved from
the config>router>mpls context to the new config>router>if-attribute context. The
binding of MPLS interfaces to admin-group or SRLG remains under
config>router>mpls>interface.
Upgrading to • Starting with Release 11.0.R7, configuration changes are required for TACACS+ servers to
Release 11.0.R7 or authorize global commands. Global commands such as info, exit, and others, except the
Higher logout command, should be explicitly added to the configuration in the TACACS+ server.
There are no changes required in the configuration on the SR OS node for this issue. A list
of all global commands can be found in the SR OS Basic System Configuration Guide, or
by entering help globals at the CLI prompt. [171214]
Upgrading from • The parameter port-forwarding-dyn-block-reservation was introduced in Release

Release 11.0.R1 or 11.0.R1 and was incorrectly allowed to be configured for type L2-Aware NAT pools. From
11.0.R2 Release 11.0.R3 onwards, a check was added to disallow the configuration of the parameter
in combination with type L2-Aware NAT pools. Prior to upgrade, the parameter port-
forwarding-dyn-block-reservation should be removed from the NAT configuration when
having a type L2-Aware NAT-group configured. More details can be found in TA 13-1007.
[163525]
LDP • When upgrading from Release 11.0.R3, 11.0.R4, or 11.0.R5 to Release 11.0.R6 or later, the
default setting for LDP event 2003 changed from generate to suppress. This value must be
manually changed after the upgrade to properly save the newly corrected default setting of
suppress. The default of suppress had been the default in Release 11.0.R2 and all prior
releases. [170911]
Upgrading to • The tmnxPortID mapping has changed for the 7950 XRS-20 platform. Refer to TIMETRA-
Release 11.0.R4 or TC-MIB for specific details.
Higher on XRS-20 • On upgrade, port indices in the SNMP MIB will not be preserved on these platforms.
Management software that expects the old mapping may need to be updated.
R-VPLS • R-VPLS does not support configuration of line card MAC filters. This restriction is now
properly enforced starting with Releases 11.0.R1 or higher. A router using an SR OS
version that enforces the restriction will not load a configuration that includes MAC filters
in the context of R-VPLS. Before loading such a configuration either from a saved file or

as part of an SR OS router upgrade, MAC filter configuration must be removed from the R-
VPLS context.
• A Routed-VPLS service does not support Multicast-VLAN-Registration (MVR). This
restriction is enforced starting from Release 11.0.R1 onwards. With Release 10.0, it was
possible to configure MVR options below a Routed-VPLS service. Before upgrading from
Release 10.0, those options must be removed from the configuration, or loading the saved
file will fail. [163006]
Filter Policy • Starting with Release 11.0.R1, SR OS enforces the rule that a single CLI filter policy entry
Consideration should not exceed the allowed hardware resources. Operators are advised to verify that a
when Upgrading 10.0 configuration that uses match list in filter policies does not exceed the recommended
from Release limit prior to an upgrade. Failure to do so will result in configuration failure during an
10.0.R4 or Higher upgrade if the entry exceeds the enforced limits. The enforced rule allows 2000 hardware
to Release 11.0.R1 sub-entries per line card filter policy entry and 256 hardware sub-entries per CPM filter
or higher policy entry (approx. 25% margin atop Release 10.0.R4 recommended/supported limits as
outlined by known limitation 142472 in Releases 10.0 and 11.0).
Refer to the Release Notes for Releases 11.0 and 10.0 for information about known limita-
tion 142472.
Upgrading to • Support for the read-only radiusServerTable and read-only tacplusServerTable in the
Release 11.0.R1 or TIMETRA-SYSTEM-MIB has been removed in Release 11.0.R1 onwards. The alternative
Higher readable and writable tables tmnxRadiusServerTable and tmnxTacPlusServerTable in the
TIMETRA-SECURITY-MIB should be used instead. [131834]
• A new support.tim file has been introduced in Release 11.0.R1 as part of the SR OS
software image package of *.tim files. All *.tim files should be copied together as a
package when performing actions such as upgrades or backing up images. The support.tim
file contains SR OS image data that is required for all platforms and configurations, and is
not related to Alcatel-Lucent support services or the admin tech-support functionality.
When upgrading from a release prior to Release 11.0.R1 to Release 11.0.R1 release or later,
the support.tim file must be manually synchronized (copied) across to the standby CPM.
See Step 5 of the Standard Software Upgrade Procedure. Releases prior to Release 11.0.R1
do not know about the support.tim file and hence the synchronize command will not copy
it.
AA Signatures Upgrade Procedure

This section describes the AA Signatures Upgrade Procedure which can be used to upgrade
ISAs in 7750 SR-7/12/12e, 7750 SR-c4/c12 and ESS-6/6v/7/12 to a new AA signature load
without upgrading/impacting the router itself:
− When no firmware update is required

If the above criterion does not apply, the Standard Software Upgrade Procedure must be
performed.
Notes:
• Although the software upgrade can be performed using a remote terminal session, Alcatel-Lucent
recommends that the software upgrade procedure be performed at the system CONSOLE device
where there is physical access to the 7750 SR or 7450 ESS as remote connectivity may not be
possible in the event there is a problem with the software upgrade. Performing the upgrade at the
CONSOLE with physical access is the best situation for troubleshooting any upgrade problems
with the help of the Alcatel-Lucent Technical Assistance Center.
• This procedure applies to all ISA cards.
STEP 1 Back up existing images and configuration files

New software loads may make modifications to the configuration file which are not compatible
with older versions of the software.
Note:
• Configuration files may become incompatible with prior releases even if no new features are
configured. The way in which a particular feature is represented in the configuration file may be
updated by the latest version of the operating software. The updated configuration file would then
be an unknown format to earlier software versions.
Alcatel-Lucent recommends making backup copies of the software image and configuration
files (including bof.cfg and *.ndx persistency files). These backups will be useful in case
reverting to the old version of the software is required.
STEP 2 Copy Application Assurance ISA-AA.TIM file to cf3:

Application Assurance software and signatures are included in the isa-aa.tim file. This file must
be copied to the same cf3: directory as the current SR OS images running on the router. It is
good practice to place all of the image files for a given release in an appropriately named
subdirectory off the root, for example, “cf3:\13.0.R1”.
As a result of this step, when upgrading the AA software only on an older SR OS software, the
new isa-aa.tim file overwrites the existing software on the flash card.
STEP 3 Synchronize boot environment

Active and standby CPM/CFM boot environments must be synchronized if the router has
redundant CPM/CFMs.
• Use admin redundancy synchronize boot-env to synchronize the boot environments
between the active and standby CPM/CFMs.
STEP 4 Load new image for ISA card

Once the boot environment has been synchronized, the new AA image needs to be loaded on
the CPM/CFM.
• Use admin application-assurance upgrade to load the new isa-aa image on the
CPM/CFM.

• Use show application-assurance version to verify new isa-aa image version running on
the CPM/CFM.
• Use show mda to verify ISA card status.
A:ALU-ABC>show>app-assure# version
==============================================================================
Versions of isa-aa.tim in use
==============================================================================
CPM : TiMOS-M-13.0.R2
1/2 : TiMOS-M-13.0.R1
3/2 : TiMOS-M-13.0.R1
==============================================================================
A:Cpm-A# show mda

==============================================================================
MDA Summary
==============================================================================
Slot MDA Provisioned Equipped Admin Operational
Mda-type Mda-type State State
------------------------------------------------------------------------------
1 2 isa-aa isa-ms up ISSU/standby
...
3 2 isa-aa isa-ms up ISSU/active
==============================================================================
STEP 5 Reset the ISA cards to load the new image

The ISA cards must now be reset to load the new image.
Note:
• The system does not allow cards to run in an ISSU state indefinitely; the system automatically
resets the ISA cards after 2 hours. The “Comments” field in the show card state output displays
the time until the system resets the ISA card in the ISSU state.
The timing and order of the ISA card resets should be sequenced to maximize the effectiveness
of any redundancy. When redundancy is deployed, protecting (standby) ISA cards should be
reset first, and admin activity switch should be forced first (config card mda m/n shutdown)
before an active ISA card is reset.
• Use shutdown mda m/n to shut down an ISA card
• Use clear mda m/n to reset an ISA card
• Use no shutdown mda m/n to enable an ISA card
• Use show application-assurance version to verify the isa-aa signatures version loaded on
the CPM/CFMs and the ISA cards
The sample output below shows the operational state transitions for a single Application
Assurance group with one (1) active and one (1) protecting (standby) ISA card.
1. Before reset starts:

==============================================================================
==============================================================================
1/2 : TiMOS-M-13.0.R1
3/2 : TiMOS-M-13.0.R1
==============================================================================
A:Cpm-A# show mda

==============================================================================
MDA Summary
==============================================================================
------------------------------------------------------------------------------
1 2 isa-aa isa-ms up ISSU/standby
...
==============================================================================
2. After the standby ISA card is reset and comes back up:
==============================================================================
==============================================================================
1/2 : TiMOS-M-13.0.R2
3/2 : TiMOS-M-13.0.R1
==============================================================================
A:Cpm-A# show mda

==============================================================================
MDA Summary
==============================================================================
------------------------------------------------------------------------------
1 2 isa-aa isa-ms up up/standby
...
==============================================================================
3. After the ISA card activity switch (shutdown of active card to force activity switch):
==============================================================================
==============================================================================
1/2 : TiMOS-M-13.0.R2
3/2 : TiMOS-M-13.0.R1
==============================================================================

A:Cpm-A# show mda

==============================================================================
MDA Summary
==============================================================================
------------------------------------------------------------------------------
1 2 isa-aa isa-ms up up/active
...
3 2 isa-aa isa-ms down ISSU/standby
==============================================================================
4. After the newly inactive ISA card is reset, comes back up (clear command executed) and is
re-enabled (no shutdown executed):
==============================================================================
==============================================================================
1/2 : TiMOS-M-13.0.R2
3/2 : TiMOS-M-13.0.R2
==============================================================================
A:Cpm-A# show mda

==============================================================================
MDA Summary
==============================================================================
------------------------------------------------------------------------------
1 2 isa-aa isa-ms up up/active
...
3 2 isa-aa isa-ms up up/standby
==============================================================================
STEP 6 Update the AA policy and enable the new applications and protocol signatures
When the CPM/CFMs and ISA cards are using the latest image, update the AA policy definition
and enable the new protocols available in this release. This process updates existing applications
and corresponding app-filters maintained by Alcatel-Lucent, and creates newly supported
applications.
• The operator must open a standard ticket, priority 3, to Alcatel-Lucent technical support,
and provide a technical support file and the target AA software release deployed in the
network.
• The technical support team will provide the following configuration update file to update
the AA policy, to be executed on the target nodes:
7750# exec ftp://user:pass@ftp-server-ip/path/<aaconfig-delta-update-file-name>

ISSU Upgrade Procedure

This section describes the ISSU Upgrade Procedure which can be used:
− when no manual firmware update is required (such as “admin reboot upgrade”)—See
the ISSU sub-section of Known Limitations for details.
− on routers running Release 12.0.R4 (12.0.R5 for 7950 XRS-16c/20 and 12.0.R6 for
7950 XRS-40) to 12.0.R16 for Major ISSU with redundant CPMs only (not
applicable to 7750 SR-a4/8 or 7750 SR-c4/12)
− on routers running Release 13.0.R4 to Release 13.0.R9 for Minor ISSU with
redundant CPMs/CFMs only (not applicable to 7750 SR-a4/8 or 7750 SR-c4)
If any of the above criteria do not apply, the Standard Software Upgrade Procedure must be
performed.
ISSU limitations listed under Known Limitations should be taken into account for planning
purposes before the ISSU is performed.
Notes:
where there is physical access as remote connectivity may not be possible in the event there is a
problem with the software upgrade. Performing the upgrade at the CONSOLE with physical
access is the best situation for troubleshooting any upgrade problems with the help of the
Alcatel-Lucent Technical Assistance Center. It is also recommended to connect to the CONSOLE
port on both CPMs/CFMs prior to starting the ISSU.
The ISSU procedure is split into the following two (2) phases:
• Phase A: Preparation and CPM/CFM Upgrade, with one procedure common to Minor and
Major ISSU
• Phase B: Completion of the ISSU, with different procedures for Minor and Major ISSU
Phase A: Phase A of the ISSU procedure is common to both Minor ISSU and Major ISSU. This phase
covers ISSU preparation and the update of the CPM/CFM software.
Preparation
and
CPM/CFM
Upgrade
STEP 1 Backup Existing Images and Configuration Files

Note:

Alcatel-Lucent recommends performing an admin save and then making backup copies of the
BOOT Loader (boot.ldr), software image and configuration files (including bof.cfg and
*.ndx persistency files). These backups will be useful in case reverting to the old version of the
software is required.
If Lawful Intercept (LI) is being used on the router and bof li-local-save is enabled, then the
operator may want to save the LI configuration via configure li save and then backup the li.cfg
file.
STEP 2 Copy SR OS Images to cf3:

The SR OS image files must be copied to the cf3: device. It is good practice to place all of the
image files for a given release in an appropriately named subdirectory off the root, for example,
“cf3:\13.0.R10”. Copying the boot.ldr and other files in a given release to a separate
subdirectory ensures that all files for the release are available should downgrading the software
version be necessary. Note that as of Release 11.0.R1, the support.tim file must also be copied
for all platforms and configurations.
STEP 3 Copy boot.ldr to the Root Directory on cf3:

The BOOT Loader file is named boot.ldr. This file must be copied to the root directory of
the cf3: device.
STEP 4 Modify the Boot Options File to Point to the New Image
The Boot Options File (bof.cfg) is read by the BOOT Loader and indicates primary,
secondary and tertiary locations for the image file.
• The bof.cfg should be modified as appropriate to point to the image file for the release
to be loaded.
• Use the bof save command to save the Boot Options File modifications.
STEP 5 Synchronize Boot Environment

Once the Boot Options File has been modified, the active and standby CPM or CFM boot
environments must be synchronized.
• Use admin redundancy synchronize boot-env to synchronize the boot environments
between the active and standby CPMs/CFMs.
STEP 6 Reboot the Standby CPM/CFM

In the sample output below, the active CPM/CFM is in Slot A and the standby CPM/CFM is in
Slot B. Before performing ISSU on systems with CPMs, the show card output will display the
information similar to the following:

A:router1# show card
==============================================================================
Card Summary
==============================================================================
Slot Provisioned Equipped Admin Operational
Card-type Card-type State State
------------------------------------------------------------------------------
2 iom-20g-b iom-20g-b up up
A sfm4-12 sfm4-12 up up/active
B sfm4-12 sfm4-12 up up/standby
==============================================================================
Before performing ISSU on systems with CFMs, the show card output will display the
information similar to the following:
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
1 iom-xp iom-xp up up
A cfm-xp cfm-xp up up/active
B cfm-xp cfm-xp up up/standby
==============================================================================
• Use admin reboot standby now to reboot the standby CPM/CFM and start the ISSU
process.
After rebooting the standby CPM, the show card output will display information similar to the
following:
A:router1# admin reboot standby now
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
B sfm4-12 up down/standby
==============================================================================

STEP 7 Wait for Standby CPM/CFM to Synchronize

After the ISSU has been initiated, the card status of the standby CPM/CFM (in Slot B in this
example) will show as “synching”, as in this example for systems with CPMs.
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
B sfm4-12 sfm4-12 up synching/standby
==============================================================================
When the standby CPM/CFM has completely synchronized, the standby CPM/CFM will
indicate a state of “ISSU”, as in the following example for systems with CPMs.
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
B sfm4-12 sfm4-12 up ISSU/standby
==============================================================================
For systems with CFMs:

==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
1 iom-xp iom-xp up up
A cfm-xp cfm-xp up up/active
B cfm-xp cfm-xp up ISSU/standby
==============================================================================
Phase B - Minor ISSU
Phase B - Major ISSU

Phase B: Phase B of the ISSU procedure is different for Minor ISSU and Major ISSU. Proceed to the
appropriate procedure.
Completion
• Phase B (Minor ISSU)
of the ISSU
• Phase B (Major ISSU)
Phase B (Minor The following steps describe the rest of the ISSU procedure for Minor ISSU.
ISSU)
STEP 8 (Minor ISSU) Switchover the CPM/CFM

After the standby CPM/CFM has synchronized and indicates a card status of “ISSU”, a
CPM/CFM switchover (from A to B in this example) must be performed in order to force the
CPM/CFM running the new software image to become the active CPM/CFM. The switchover
command will cause the active CPM/CFM to reboot.
• Use admin redundancy force-switchover to make the CPM/CFM with the new software
image become the active CPM.
Note that, when the switchover command is issued, a warning will be printed if any cards are
equipped:
WARNING: After switchover, the following resets will be needed:
For each IOM/IMM that is equipped, regardless of state, a one (1) line summary is displayed to
indicate whether the card will be hard reset or Soft Reset, along with a reason for the hard reset.
See Step 8 of the Major ISSU procedure for more details.
Note:
• The isa-bb ISA cards will be automatically placed into a failed state by SR OS when the
force-switchover command is executed (for minor ISSU) until their host IOM is reset in
Step 11.
STEP 9 (Minor ISSU) If Necessary, Re-establish a Console Session

If the ISSU is performed from the serial port CONSOLE on the CPM/CFM and there is only
one terminal available (that is, one PC with a serial port), the console session must be re-
established on the newly active CPM/CFM.
STEP 10 (Minor ISSU) Wait for Standby CPM/CFM to Synchronize

Before continuing with the ISSU procedure, the standby CPM/CFM must re-synchronize by
transitioning from “down”, to “synchronizing”, and finally to the “up” state. Use the show card
command to monitor the status of the IOMs and IMMs. Note that the IOMs and IMMs now have
an “ISSU” status indicating that the active CPM/CFM is running the new image, as in this
example for systems equipped with CPMs.
B:router1# show card

==============================================================================
Card Summary
==============================================================================


------------------------------------------------------------------------------
2 iom-20g-b iom-20g-b up ISSU
A sfm4-12 up down/standby
B sfm4-12 sfm4-12 up up/active
==============================================================================
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
A sfm4-12 sfm4-12 up synching/standby
==============================================================================
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
A sfm4-12 sfm4-12 up up/standby
==============================================================================
For systems equipped with CFMs, the CMAs/MDAs will never show an operational state of
“ISSU”. For CMAs/MDAs that require a hard reset, the operator may see “unequipped”,
“booting”, and then “up”
STEP 11 (Minor ISSU) Reset the line cards to Load the New Image
The IOMs, ISMs, and IMMs must now be reset to load the new image. This step is not necessary
for the 7750 SR-c12. If the cards will be Soft Reset (see below), see Soft Reset in the Known
Limitations section for the source/starting release of the upgrade. Soft Reset limitations should
be taken into account for planning purposes before the ISSU is performed.
• Use the clear card n soft hard-reset-unsupported-mdas command to Soft Reset a line
card. The line card data path and MDAs/ISAs are not reset in Soft Reset compatible cases,
resulting in a very brief service interruption.

• If the Soft Reset is blocked, then use the clear card n command to hard reset the line card.
This will reboot the line card and its MDAs and ISAs, causing an outage for the duration of
the reboot..
Notes:
• The system does not allow cards to run in an ISSU state indefinitely; the system automatically
hard resets the IOMs/IMMs/ISMs after two (2) hours. The “Comments” field in the show card
state output displays the time until the system resets the line cards in the ISSU state.
• It is recommended to Soft Reset no more than one line card at a time to ensure that the line card
download process does not impact control plane protocols. Wait for the operational state to be
“up” before proceeding to the next line card.
• With the Deferred MDA Reset enhancement (introduced in Release 10.0.R1), Soft Reset of a card
is allowed to proceed even when the MDA firmware does not match the MDA firmware in the
new image. The operator is informed of MDAs running below the latest revision of firmware with
CHASSIS log event #2082. The MDA can be upgraded to the latest firmware (after the Soft
Reset) by performing a hard reset of the MDA (clear mda x/y).
The sample output below shows the operational state transition for a single line card.
B:SoftReset1# clear card 4 soft
B:SoftReset1# show card
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
4 iom-20g-b up soft reset
========================================================================
When the IOM/IMM/ISM is in the “up” state, it will have the new image so it will no longer
have an “ISSU” operational state as shown in the sample output below.
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
==============================================================================

The timing and order of the line card resets should be sequenced to maximize the effectiveness
of any redundant interfaces (LAGs, VRRP, etc.) spanning IOM/IMM/ISM, MDA, or any ISA
redundancy deployed slots.
The sample output below shows the operational state transitions for a single IOM in a system
equipped with CPMs.
B:router1# clear card 2
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
2 iom-20g-b up provisioned
==============================================================================
When the line card is in the “up” state, it will have the new image so it will no longer have an
“ISSU” operational state as shown in the sample output below.
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
==============================================================================
When all of the line cards have been rebooted, the ISSU is complete. It is recommended to save
the configuration (admin save) after an upgrade has been performed and the system is operating
as expected. This will ensure that all configurations are saved in a format that is fully compatible
with the newly running release.
Phase B (Major The following steps describe Phase B of the ISSU procedure for Major ISSU.
ISSU)

STEP 8 (Major ISSU) Switchover the CPM

Once the standby CPM has synchronized (Operational State = ISSU/standby), then the operator
can proceed to the next phase of Major ISSU.
Note that if the standby CPM is being held in the “down” operational state, take a look at log 99
for log events that explain the reason. For example, if the system contains deprecated hardware
such as the m4-choc3-sfp:
122 2015/05/30 16:21:03.83 EDT MAJOR: CHASSIS #2001 Base Card B
"Class CPM Module : failed, reason: Issu Unsupported Scenario, No Reload"
121 2015/05/30 16:21:03.84 EDT MAJOR: CHASSIS #2001 Base Card B

"Class CPM Module : failed, reason: Unsupported MDA type m4-choc3-sfp in
slot 1/2"
After the standby CPM has synchronized and indicates a card status of “ISSU/standby”, a CPM
switchover (from A to B in this example) must be performed in order to force the CPM running
the new software image to become the active CPM. The switchover command will cause the
active CPM to reboot.
• Use admin redundancy force-switchover to make the CPM with the new software image
become the active CPM.
Note that if the active CPM reboots for any reason other than the force-switchover command,
then the ISSU will be terminated and a full node reboot will occur.
When the switchover command is issued, a warning will be printed if any cards are equipped:
WARNING: After switchover the following HARD and SOFT resets will occur:
For each line card that is equipped, regardless of its state, a one (1) line summary is displayed
to indicate whether the card will be hard reset or Soft Reset, along with a reason for the hard
reset. The following example shows a particular card and MDA configuration, along with the
resulting ISSU hard reset or Soft Reset reasons.
A:Dut-A# show card
==============================================================================
Card Summary
==============================================================================
Slot Provisioned Equipped Admin Operational Comments
------------------------------------------------------------------------------
1 imm1-100gb-cfp imm1-100gb-cfp up up
2 imm12-10gb-sf+ imm12-10gb-sf+ up up
3 imm5-10gb-xfp imm5-10gb-xfp up up
4 iom3-xp-b up unprovisioned
5 iom2-20g iom2-20g up up
7 imm3-40gb-qsfp imm3-40gb-qsfp up up
10 iom3-xp iom3-xp up up
B sfm4-12 sfm4-12 up ISSU/standby
==============================================================================
A:Dut-A# show mda

==============================================================================
MDA Summary

==============================================================================
Slot Mda Provisioned Equipped Admin Operational
------------------------------------------------------------------------------
1 1 imm1-100gb-xp-cfp imm1-100gb-xp-cfp up up
2 1 imm12-10gb-xp-sf+ imm12-10gb-xp-sf+ up up
3 1 imm5-10gb-xp-xfp imm5-10gb-xp-xfp up up
5 1 m20-1gb-xp-sfp m20-1gb-xp-sfp up up
2 m4-choc3-as-sfp m4-choc3-as-sfp up up
7 1 imm3-40gb-xp-qsfp imm3-40gb-xp-qsfp up up
8 1 m2-10gb-xp-xfp m2-10gb-xp-xfp up up
2 m1-10gb-dwdm-tun m1-10gb-dwdm-tun up up
9 2 m4-choc3-as-sfp m4-choc3-as-sfp up up
10 1 m10-1gb-xp-sfp m10-1gb-xp-sfp up up
2 m10-1gb-hs-sfp-b m10-1gb-hs-sfp-b up up
==============================================================================
A:Dut-A# admin redundancy force-switchover

WARNING: After switchover the following HARD and SOFT resets will occur:
IOM 1: SOFT (MDAs: 1/1 SOFT)
IOM 4: HARD (offline)
IOM 5: SOFT (MDAs: 5/1 SOFT, 5/2 HARD (unsupported))
IOM 7: HARD (no Soft Reset capable MDAs: 7/1 incompatible)
IOM 8: SOFT (MDAs: 8/1 SOFT, 8/2 SOFT)
IOM 9: HARD (no Soft Reset capable MDAs: 9/1 not present, 9/2 unsupported)
IOM 10: SOFT (MDAs: 10/1 SOFT, 10/2 SOFT)
The reason codes are as follows:

• unsupported: Soft Reset not supported on the assembly
• incompatible: the specific upgrade scenario being attempted (from software image X to
software image Y) is not Soft Reset compatible (for example: mandatory datapath firmware
upgrades on an MDA or IMM)
• offline: the assembly is not currently operational
• not present: the card or MDA is not present
• any MDA hard reset forces IOM hard reset: one of the MDAs cannot be upgraded without
IOM hard reset
No reason codes are given for MDAs that are shut down (a reset of those MDAs will have no
impact on service), or for the second MDA identifier in a slot that contains an IMM.
After the IOM summary, the following prompt is given to the operator:
WARNING: Major in service software upgrade in progress.
Are you sure you want to switchover (y/n)?
The switchover may be blocked in various error scenarios. A warning will explain the problem.
For example, the following message will occur if the standby does not have enough compact
flash space for the configuration to be synchronized:
MINOR: CHMGR #1055 - Major ISSU sync of config to standby failed

If the switchover is attempted when the standby is not in an “ISSU/standby” state, then normal
High-Availability switchover behavior will apply.
STEP 9 (Major ISSU) If Necessary, Re-establish a Console Session

If the ISSU is performed from the serial port CONSOLE on the CPM, and there is only one
terminal available (i.e., one PC with a serial port), the console session must be re-established on
the newly active CPM.
STEP 10 (Major ISSU) Line Card Update

When the switchover command is used in Major ISSU, the active CPM will prepare the system
for the ISSU and then reboot. The other CPM (previously the standby and running the newer
software load) will take over as the active CPM.
After the switchover, a command prompt will be available on the newly active CPM.
Configuration changes are not allowed at this point, but most show, clear and admin
commands are available. If the operator attempts to use a command that is invalid during this
phase, they will receive the following error:
*B:Dut-A# configure service epipe 3 customer 1 create
MINOR: CLI Command not allowed while becoming active.
Once the Major ISSU is complete, the full CLI functionality will be available.
Shortly after the switchover, all line cards are reset so that they can upgrade to the new image.
The reset will be a Soft Reset for any supported combinations of cards, and hard reset for all
other cases (with reasons displayed for each line card as described in previous steps).
Note:
• The Soft Reset section of the Known Limitations in the Release Notes for the
source/starting release of the upgrade should be taken into account for planning
purposes before the ISSU is performed.
The sample output below shows the operational state transition for the cards in the system.
After the CPM running the new software image first takes over:
TiMOS-C-11.0.B1-106 cpm/hops ALCATEL SR 7750 Copyright (c) 2000-2015 Alcatel-
Lucent.
Login: admin
Password:
*B:Dut-A# show redundancy synchronization

==============================================================================
Synchronization Information
==============================================================================
Standby Status : disabled
Last Standby Failure : N/A
Standby Up Time : N/A
Standby Version : N/A
Failover Time : 05/30/2015 16:00:33
Failover Reason : user forced switchover
Boot/Config Sync Mode : None
Boot/Config Sync Status : No synchronization

Last Config File Sync Time : Never

Last Boot Env Sync Time : Never
Rollback Sync Mode : None
Rollback Sync Status : No Rollback synchronization
Last Rollback Sync Time : Never
==============================================================================
*B:Dut-A# show card

==============================================================================
Card Summary
==============================================================================
Slot Provisioned Type Admin Operational Comments
Equipped Type (if different) State State
------------------------------------------------------------------------------
1 imm1-100gb-cfp up soft reset
(not equipped)
2 imm12-10gb-sf+ up soft reset
(not equipped)
3 imm5-10gb-xfp up soft reset
(not equipped)
5 iom2-20g up soft reset
(not equipped)
7 imm3-40gb-qsfp up provisioned
(not equipped)
(not equipped)
9 iom2-20g up provisioned
(not equipped)
10 iom3-xp up soft reset
(not equipped)
(not equipped)
B sfm4-12 up up/active
==============================================================================
A few seconds later, most of the cards have been detected and are in the Soft Reset or booting
state. The standby CPM will remain as “down/standby” until all Soft Resets are completed.
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
1 imm1-100gb-cfp up soft reset
2 imm12-10gb-sf+ up soft reset
3 imm5-10gb-xfp up soft reset
4 (not provisioned) up unprovisioned
iom3-xp-b
7 imm3-40gb-qsfp up booting
9 iom2-20g up booting
10 iom3-xp up soft reset
==============================================================================

The following output shows the cards having completed their resets and are now running with
the new software image. The standby CPM will synchronize with the active CPM once all Soft
Resets are completed.
==============================================================================
Card Summary
==============================================================================
=
------------------------------------------------------------------------------
1 imm1-100gb-cfp up up
2 imm12-10gb-sf+ up up
3 imm5-10gb-xfp up up
iom3-xp-b
5 iom2-20g up up
7 imm3-40gb-qsfp up up
8 iom2-20g up up
9 iom2-20g up up
10 iom3-xp up up
A sfm4-12 up synching/standby
==============================================================================
STEP 11 (Major ISSU) ISSU Completion

Monitor the node to ensure that it returns to normal operation. All IOMs/IMMs/ISMs should
return to the “up” state, and the standby CPM should return to the operational “up” state. Note
that the standby CPM may spend a few minutes in the synching state before finally settling in
the “up” state.
The following output shows the IOM/IMMs backed up, and the standby CPM synchronized
(“up”).
==============================================================================
Card Summary
==============================================================================
------------------------------------------------------------------------------
1 imm1-100gb-cfp up up
2 imm12-10gb-sf+ up up
3 imm5-10gb-xfp up up
iom3-xp-b
5 iom2-20g up up
7 imm3-40gb-qsfp up up
8 iom2-20g up up
9 iom2-20g up up
10 iom3-xp up up
A sfm4-12 up up/standby
==============================================================================
*B:Dut-A# show redundancy synchronization

==============================================================================
Synchronization Information
==============================================================================
Standby Status : standby ready
Last Standby Failure : N/A
Standby Up Time : 2015/05/30 16:05:03
Standby Version : ...<version info>...
Failover Time : 05/30/2015 16:00:33
Failover Reason : user forced switchover
Boot/Config Sync Mode : None
Boot/Config Sync Status : No synchronization
Last Config File Sync Time : Never
Last Boot Env Sync Time : Never
Rollback Sync Mode : None
Rollback Sync Status : No Rollback synchronization
Last Rollback Sync Time : Never
==============================================================================
When all of the line cards have been rebooted, and the active and standby CPMs are in sync, the
ISSU is complete. Full CLI functionality will be available at this point.
Alcatel-Lucent recommends saving the configuration (admin save) after an upgrade has been
performed and the system is operating as expected. This will ensure that all configurations are
saved in a format that is fully compatible with the newly running release.
STEP 12 (Major ISSU) Optional Post-ISSU Actions

• With the Deferred MDA Reset enhancement, Soft Reset of a card is allowed to proceed
even when the MDA firmware does not match the MDA firmware in the new image. The
operator is informed of MDAs running below the latest revision of firmware with
CHASSIS log event #2082. The MDA can be upgraded to the latest firmware (after the
Soft Reset) by performing a hard reset of the MDA (clear mda x/y).
Standard Software Upgrade Procedure

This section describes the Standard Software Upgrade Procedure that is service-affecting and
must be used:
− when a manual firmware update is required (that is, admin reboot upgrade).
− on routers with non-redundant CPM or CFM
− on 7750 SR-a4/a8
− when ISSU is not supported in a given release
Each software release includes a BOOT Loader (boot.ldr). The BOOT Loader performs two
functions:
1. Initiates the loading of the SR OS image based on the Boot Options File (bof.cfg) set-
tings
2. Reprograms the boot ROM and firmware code on the CPM or CFM and
IOM/IMM/ISM/XCM cards to the version appropriate for the SR OS image.
This section describes the process for upgrading the software and, if necessary, the boot ROM
and firmware images with the BOOT Loader.

The software checks the firmware images on the CPM or CFM and IOM/IMM/ISM/XCM and
reports any mismatch. If the loaded version is earlier than the expected version, the firmware
may need to be upgraded; a console or log message will indicate if a firmware upgrade is
required. If the firmware version loaded is later than the expected version, no firmware pro-
gramming is required.
Notes:
• An admin reboot upgrade is required for all 7450 ESS-6/6v chassis running Release 8.0 or an
earlier major release, Release 9.0.R22 or an earlier 9.0 minor release, Release 10.0.R12 or an
earlier 10.0 minor release, or Release 11.0.R3 or an earlier 11.0 minor release.
where there is physical access as remote connectivity may not be possible in the event there is a
problem with the software upgrade. Performing the upgrade at the CONSOLE with physical
access is the best situation for troubleshooting any upgrade problems with the help of the
Alcatel-Lucent Technical Assistance Center.
• Automatic firmware updates may occur for CPM and IOM/IMM/ISM/XCM cards running older
firmware after a SR OS upgrade. The clear card command or physical removal of a card must not
be performed until the card is operationally up after an SR OS upgrade. This procedure also
applies when subsequently adding new IOMs/IMMs/ISMs/XCMs (that may have older firmware)
to a chassis. An event log with “firmware upgraded” message will be issued if a firmware update
had occurred for a card.
STEP 1 Back up existing images and configuration files

Note:
Alcatel-Lucent recommends performing an admin save and then making backup copies of the
BOOT Loader (boot.ldr), software image and configuration files (including bof.cfg and
*.ndx persistency files). These backups will be useful in case reverting to the old version of the
software is required.
If Lawful Intercept (LI) is being used on the router and bof li-local-save is enabled, then the
operator may want to save the LI configuration via configure li save and then backup the li.cfg
file.
If the firmware version loaded is later than the expected version reported by the BOOT Loader,
no firmware programming is required.

STEP 2 Copy the SR OS images to cf3:

The SR OS image files must to be copied to the cf3: device on the CPM or CFM. It is good
practice to place all the image files for a given release in an appropriately named subdirectory
off the root, for example, “cf3:\13.0.R10”. Copying the boot.ldr and other files in a given
release to a separate subdirectory ensures that all files for the release are available should
downgrading the software version be necessary.
Note:
• As of Release 11.0.R1, the support.tim file must also be copied for all platforms and
configurations.
STEP 3 Copy boot.ldr to the root directory on cf3:

The BOOT Loader file is named boot.ldr. This file must be copied to the root directory of
the cf3: device.
STEP 4 Modify the Boot Options File to boot the new image
The Boot Options File (bof.cfg) is read by the BOOT Loader and indicates primary,
secondary and tertiary locations for the image file. The bof.cfg should be modified as
appropriate to point to the image file for the release to be loaded. Use the bof save command to
save the Boot Options File modifications.
STEP 5 [Redundant CPMs or CFMs] synchronize boot environment

On systems with Redundant CPMs or CFMs, copy the image files and Boot Options File to the
redundant CPM or CFM with admin redundancy synchronize boot-env.
When upgrading from a release prior to Release 11.0.R1 to Release 11.0.R1 or later, the
support.tim file must be manually synchronized (copied) across to the standby CPM/CFM.
Releases prior to Release 11.0.R1 do not use the support.tim file and hence the synchronize
command will not copy it.
STEP 6 Reboot the chassis

The chassis should be rebooted with the admin reboot command.
STEP 7 Verify the software upgrade

Allow the boot sequence to complete and verify that all cards come online.
Software upgrade is successfully executed if the parsing of the configuration file completes as
expected and there are no errors shown via a CONSOLE session or in the output of the show
boot-messages CLI command.
If the configuration-file parsing stops with the error “CRITICAL: CLI #1002 The system
configuration is missing or incomplete because an error occurred while processing the
configuration file”, then check for known causes in the Release Notes or contact your Alcatel-
Lucent support organization. Executing admin save at this point could result in the loss of the
configuration.

To continue with the configuration-file parsing, remove the conflicting parameter from the
loaded configuration file and re-execute it using the execute CLI command, or leave the loaded
configuration file untouched and revert to the old version of the software.
Note:
• If any card fails to come online after the upgrade, contact the Alcatel-Lucent Technical Assistance
Center for information on corrective actions.
Alcatel-Lucent recommends saving the configuration with admin save after an upgrade has
been performed and the system is operating as expected. This will ensure that all configuration
is saved in a format that is fully compatible with the newly-running release.

Known Limitations
Known Limitations
The following sections describe the known limitations for SR OS Release 13.0.R10.
Notes:
• Known limitations added in this release are marked with an asterisk. (*)
• Bracketed [ ] references are internal tracking numbers.
HW/Platform • The OES ports on the CCM-X20 and CPM5 are not supported (reserved for future use).
• The Sync-E/IEEE 1588 port on the CCM-X20 and CPM5 are not supported (reserved for
future use).
• The LCD panel on the CCM-X20 is not supported (reserved for future use).
• The E-SATA interface on the CPM-X20 is not supported (reserved for future use).
• If an SFM-400G is replaced with an SFM-200G, the “card provisioned” field will continue
to display SFM-400G. This indicates that the slot is capable of containing both types of
SFMs. [27116]
• The link LED and operational status of a 10GBASE WAN-PHY port is tied to the Ethernet
channel's ability to obtain frame-lock, so if there is a SONET issue such as PPLM, the link
LED will not be lit, even though the SONET connection might otherwise be valid. [35354]
• A SONET/SDH port that is shut down or in internal loopback is incorrectly being allowed
as a valid synchronous timing reference. [36448]
• After a High Availability switchover on a c8-chds1, c4-ds3 or c1-choc3-ces-sfp CMA, if
the system detects a configuration mismatch between the SF/CFM and CMA, the CMA
will automatically reset and the following message will be displayed on the console (for
example, on MDA slot 1): “redDynamic:WDDI:winpathHwAudit Configuration out of
sync between SF/CFM and MDA 1. Clearing the MDA to recover.”. [67797]
• The 3HE04116AA (SFP – 100/1000 FX SGMII 2KM ROHS 6/6) functions as dual-rate
only when used with another 3HE04116AA. [67690]
• When an m1-choc3-ces-sfp or m4-choc3-ces-sfp MDA is installed in an IOM3-XP, a
larger-than-expected phase transition may be experienced when performing an adaptive
clock recovery. [78408]
• A limit of two MDAs of type ATM, ASAP or CES are supported in a 7750 SR-c4/c12
system. For example, the limitation is reached with one m4-atmoc12/3-sfp and one m12-
chds3-as. This applies to MDAs only and not to CES CMAs.
• On the 7750 SR-c4/c12, the 5-port GigE CMA cannot co-exist beside any of the other
lower-bandwidth CMAs (including 1-port GigE and other lower-speed interfaces) in odd-
even slot pairs (for example, slots 1&2, 3&4, 5&6, 7&8, 9&10 and 11&12). However, it is
possible to have a 5-port GigE CMA in slot 2 beside a 1-port GigE in slot 3.
• Ethernet hold-timer on an m1-10gb-dwdm-tun MDA will be off by 300 ms to one (1)
second because it may take longer for the port to come up. [91562]
• Due to event suppression of Ethernet port states, a port that bounces while transitioning up
or down may not take on its steady state for at least a second. Any port hold-timer
configuration of less than one (1) second will effectively look like a one (1) second hold-
timer. [91563]

Known Limitations
• The 7450 ESS-6/6v does not support CPM queue rate limiting. With the minimum and
maximum cpm-queue rate configuration, only the length of the CPM queue will be set:
max will install the maximum allowed queue length and allow bigger bursts while min
allows very limited or no bursts. [95847]
• When the active and inactive CPM types are different, the provisioned card-type for both
the active and inactive CPM will display the card-type of the active CPM. The equipped
card-type will still display properly. [105862]
• When a differential DS1 on a CEM CMA/MDA is deleted and reconfigured as a
differential E1, the recovered clock on the E1 may go into holdover. The clock recovery
can be restored on the E1 with the CMA/MDA clear command. [109738]
• Assigning the same hi-bw-mcast-src group to an IOM-20g-b/IOM2-20g forwarding
complex and IOM3-XP/IMM forwarding complex will not work correctly since the
number of multicast capable paths is different between these card types; these
configurations must not be used. [118443]
• 7750 SR-7 SF/CPM4 (3HE05949AA) is not supported in the 7750 SR-12 chassis.
Similarly, 7450 ESS-7 SF/CPM4 (3HE05951AA) is not supported in the 7450 ESS-12
chassis.
• 7750 SR-12 SF/CPM4 (3HE05948AA) is not supported in the 7750 SR-7 chassis.
Similarly, 7450 ESS-12 SF/CPM4 (3HE05950AA) is not supported in the 7450 ESS-7
chassis.
• The number of available multicast planes for 12-port 10G Ethernet IMMs running in
chassis mode C may be reduced. [123466]
• On the m4-chds3-as and m12-chds3-as MDAs, when a DS1 channel with SF framing and
no occupied timeslots is active, the remote port will interpret its content as containing an
RAI signal. This cannot be prevented, but only occurs when there are no channel-groups
configured on the channel. If there are one or more channel-groups configured on the
channel, it will still intermittently send “phantom” RAIs. However, this can be prevented
by configuring at least one group to have “idle-cycle-flags ones”. This issue does not affect
other ASAP MDAs. [129991]
• For 802.3 clause 50 compliant operation of 10G WAN-PHY ports on either SONET or
SDH infrastructure, only the use of the SONET (default) framing option is supported (that
is, config>port x/y/z>sonet-sdh>framing>sonet). Although the system allows the user to
configure framing sdh, this is an invalid configuration on a 10G WAN port. Interop issues
may occur when attempting to use any of the following card types in SDH mode: m1-10gb-
xp-xfp, m2-10gb-xp-xfp, m4-10gb-xp-xfp, imm4-10gb-xfp, imm8-10gb-xfp, imm5-10gb-
xfp, and icm2-10gb-xp-xfp. [131400]
• When a chassis-mode downgrade is performed to mode A, the downgrade may fail if an
IPv6 address is configured in the BOF. To complete a chassis mode downgrade, remove the
IPv6 address from the BOF, downgrade to mode A, and then reconfigure the IPv6 address
in the BOF.
• On the 10GE HS-MDAv2 when the agg-rate-limit option is enabled for subscribers in a
subscriber-profile, strict priority scheduling among traffic classes is not always maintained.
To achieve strict priority scheduling, use subscriber agg-rate-limit in combination with
port-scheduler-policy or exp-secondary-shaper. [159449]
• The 1-port 10GE HS-MDAv2 FPGA has a per-queue limit of around 2 Gb/s at a 64 byte
fixed frame size. For a frame size of 64 bytes, the user needs at least five (5) HS-MDAv2

Known Limitations
queues for the full 10 Gb/s port bandwidth with 2 Gb/s per queue. For higher frame sizes
(around 400 bytes), full 10 Gb/s can be achieved with a single queue. [166778]
AUX Port • The AUX port on the SF/CPM or CFM is not supported in software. SR OS does not
provide a means of configuring the device.
Synchronization • The Quality Level advertised on SyncE connections on the Extension chassis of a 7950
XRS-40 is the Quality Level of the master chassis. This means that the extension chassis
must be traceable to the same source as is used by the master chassis. Refer to the 7950
XRS-20 and XRS-40 Installation Guide for details on the proper installation cabling to
facilitate this traceability.
• On a 7950 XRS-40, the standby CPM on the extension chassis reports a Quality Level of
Stratum 3 (st3) even though it is properly synchronized to the active CPM of the Extension
chassis [181343].
• On a 7950 XRS-40, the Extension chassis will wrongly report free run after activity switch
on the Extension chassis when the Extension chassis is in holdover state [185379].
RADIUS • If the system IP address is not configured, RADIUS user-authentication will not be
attempted for in-band RADIUS servers unless a source-address entry for RADIUS exists.
• The NAS IP-address selected is that of the management interface for out-of-band RADIUS
servers. For in-band RADIUS servers if a source-address entry is configured, the source-
address IP-address is used as the NAS IP address; otherwise, the IP-address of the system
interface is used.
• SNMP access cannot be authorized for users by the RADIUS server. RADIUS can be used
to authorize access to a user by FTP, console or both.
• If the first server in the list cannot find a user, the server will reject the authentication
attempt. In this case, the router does not query the next server in the RADIUS server list
and denies access. If multiple RADIUS servers are used, the software assumes they all
have the same user database.
• In defining RADIUS Vendor-Specific Attributes (VSAs), the TiMetra-Default-Action
parameter is required even if the TiMetra-Cmd VSA is not used. [13449]
• Configuring a fallback-action under config>subscriber-mgmt>authentication-policy to
accept should not be combined with managed SAPs. Instead, Alcatel-Lucent recommends
setting fallback-action to user-db name and configuring a default host to catch all entries
and to provide default values for managed-SAP parameters.
TACACS+ • If the TACACS+ start-stop option is enabled for accounting, every command will result in
two commands in the accounting log.
• If TACACS+ is first in the authentication order and a TACACS+ server is reachable, the
user will be authenticated for access. If the user is authenticated, the user can access the
console and any rights assigned to the default TACACS+ authenticated user template
(config>system>security>user-template tacplus_default). Unlike RADIUS, TACACS+
does not have fine granularity for authorization to detail if the user has just console or FTP
access, but a default template is supported for all TACACS+ authenticated users.

Known Limitations
If TACACS+ is first in the authentication order and the TACACS+ server is NOT reach-
able, authorization for console access for the user is checked against the user’s local or
RADIUS profile if configured. If the user is not authorized in the local/RADIUS profile,
the user is not allowed to access the node.
Note that inconsistencies can arise depending upon combinations of the local, RADIUS
and TACACS+ configuration. For example, if the local profile restricts the user to only
FTP access, the authentication order is TACACS+ before local. If the TACACS+ server is
UP and the TACACS+ default user template allows console access, an authenticated
TACACS+ user will be able to log into the console using the default user template because
TACACS+ does NOT provide granularity in terms of granting FTP or console access. If the
TACACS+ server is DOWN, the user will be denied access to the console as the local pro-
file only authorizes FTP access. [39392]
CLI • The CLI allows the user to specify a TFTP location for the destination for the admin save
and admin debug-save commands which will overwrite any existing file of the specified
name. [18554]
• Non-printable, 7-bit ASCII characters are not allowed inside the various description fields.
[93998]
• Output modifiers (“| match” and “>”) are not supported in configuration files executed
using the exec command (scripts).
• Configuration rollback is not supported across major releases. The software release major
version of a node on which a rollback revert is being executed must match the software
release major version used to produce the rollback checkpoint.
• The no debug command does not remove the debug mirror information. [115892]
• Candidate commands (for example, candidate edit) cannot be used in an exec script and
cannot be used in a cron job.
• A candidate configuration (created via candidate edit) is not preserved when a CPM/CFM
failover occurs (the candidate will be empty).
• When storing files in a root directory using the admin save ftp command, explicitly
providing “/./” may be required for some FTP server implementations. This limitation does
not apply to storing files in a sub-directory. [226009]
System • Port-level and SAP-level statistics do not reflect packets processed by the CPM or CFM,
for example, packets destined to a router IP address or a packet with the router alert options
set. Another case is where DHCP Relay packets ingress on a spoke-SDP bound to an IES
interface as these packets are first sent to the CPU, so the SDP does not reflect that these
are ingressing packets. [16330]
• The 7750 SR-7/12/12e and 7450 ESS-7/12 chassis cannot differentiate between a missing
and non-functioning fan tray. [17756]
• Dropped incoming packets due to a packet processing error are not being counted in the
ifInErrors SNMP counter. Examples of packets such as this include any packet with a
malformed IP header. [27699]
• Collision events detected on a CPM or CFM management Ethernet port are reported as
CRC/Alignment errors. [30205]

Known Limitations
• All IOM/IMM/XCM-based statistics (port, interface,...) are locally maintained on the

IOM/IMM/XCM, not the CPM. IOM/IMM/XCM counters are not cleared when a clear
command is issued; the CPM stores the reference values for the last clear operation and
calculates the new values based on the values reported by the IOM/IMM/XCM. The
reference values are not maintained between the active and standby CPM, so if a CPM
switchover occurs, the newly active CPM will display the current values read directly from
the IOM/IMM/XCM regardless of any clear command issued on the other CPM. [30444]
• When a fan is removed from a 7750 SR-7/12/12e or 7450 ESS-7/12, an erroneous “fan
high temperature” alarm is generated that is cleared when the fan is replaced. [36112]
• Source address configuration applies only to the Base routing instance, and where
applicable, to VPRN services. As such, source address configuration does not apply to
unsolicited packets sent out the management interface.
• TIMETRA-PORT-MIB.mib does not include an entry for “Link Length support” as an
attribute of a Gigabit Ethernet port. This prevents Alcatel-Lucent 5620 SAM from
reporting the value even though this attribute is reported in the CLI. [46225]
• After 497 days, system up-time will wrap around due to the standard RFC 1213 MIB-II 32-
bit limit. [51129]
• Remapping of control plane traffic from a default CPM queue to a different queue is not
supported on the 7750 SR-c4/c12. [59438]
• When the password-aging option is enabled, the reference time is the time of the last boot
and not the current time. Password expiry will also be reset on every reboot. [64581]
• Prior to Release 8.0.R7, on a redundant chassis using SF/CPM3, both the active and
standby SF/CPM needed to be of the same type. Starting with Release 8.0.R7, during an
SF/CPM upgrade from type 1/2 to type 3, an SF/CPM3 can now be in a standby role.
However, the reverse is still not possible: an SF/CPM1/2 cannot boot up as standby of an
SF/CPM3. Also, in-service upgrades from SF/CPM1/2/3 to SF/CPM4 and from
SF/CPM1/2/3/4 to SF/CPM5 are not supported.
• PCS High BER conditions on Ethernet ports are not being alarmed as a separate alarm
condition and are incorrectly reported as a Local Fault. [98366]
• CPM IPv6 filters have no effect when enabled on a 7450 ESS-6/6v running in mixed mode.
[140984]
• Although extracted control traffic that arrives on a network interface but inside a tunnel and
logically terminates on a service is supposed to bypass the Distributed CPU Protection
(DCP) function, VPRN trace packets (oam vprn-trace), in this case, will be subject to
DCP.
• The following considerations apply to the IF-MIB enhancements introduced in Release
11.0.R5:
− The enable-ingress-stats option must be enabled in CLI in order to increment the
ingress IF-MIB counters for transit traffic. Ingress IF-MIB counters are updated even
if a packet is discarded on an incoming interface. The OID ifInDiscards is
incremented if a packet is dropped as a result of a uRPF failure.
− If a drop filter is configured on an incoming interface, ifInDiscards counters will be
updated for IES/VPRN interfaces, but not for Base router or management router
interfaces.
− The following commonalities exist between IES/VPRN and Base router or
management router interface counters:

Known Limitations
− Discard packets that need fragmentation but the DF bit is set: ifOutDiscards is
updated
− Discarded Broadcast-traffic: InDiscard is not updated
− Data traffic is not reflected in the counters for a tunnel interface. Only control
traffic (for example, LDP, RSVP, OSPF, IS-IS) will update the counters for a
tunnel interface
− Multicast traffic is reported in the unicast counters, but will not be reported in the
case of a tunnel interface.s
− Counters in the ifXTable and ifTable of the IF-MIB may not be updated properly
during a High-Availability switchover or after a clear router interface statistics
command. [146878]
• The queuing structures for incoming extracted control traffic on the 7450 ESS-6/6v do not
distinguish between normal control traffic and control traffic that has been marked as low
priority by CPU-protection (the out-profile-rate). [158875]
• The MIB variable “tmnxCpmCardMemorySize” reports memory size as 3292Mbytes for
an SR OS-based VM provisioned with more than 4G of memory. To verify the actual
memory size on an SR OS-based VM, one should read the MIB variables
“tmnxCardMemResMemoryAvailable”, “tmnxCardMemResMemoryUsed” and
“tmnxCardMemResPoolsAllocated”. [182316]
• Too many files in a single subdirectory can result in longer read or write operations and
eventually cause performance degradation of applications that regular need to access the
compact flash. This is a limitation of FAT file system. [192499]
• The following differences are observable in iom2-20g and FP2- and higher-based line cards
interface counters:
− When using the [no] enable-ingress-stats command, packet counters are different.
Note that, previously, the no enable-ingress-stats command set all CLI and SNMP
ingress counters to N/A and 0. Now, the no enable-ingress-stats command applies
only to ingress IPv4 and IPv6 counters.
− For iom2-20g on CPM-based traffic counters, control-plane traffic is not counted and
results in missing FCS information. IP Interface statistics (for FP2- and higher-based
line cards only) count control-plane traffic on IOM, so the FCS is counted in those
results.
− Malformed IP packets are counted on FP2- and higher-based line cards (IP interface
statistics) but not on iom2-20g (SAP statistics). SAP statistics do not include
malformed packets.
− Ingress interface statistics are reset to zero (0) after a CPM-High-Availability
switchover on iom2-20g.
− IPv4 packets are discarded due to a “do-not-fragment” message. On FP2- and higher-
based line cards, egress discards are always increased, even when a “do-not-
fragment” message is not sent. On iom2-20g, egress discards are never increased,
even when a “do-not-fragment” message is sent. [193662]
• OOB management Ethernet port redundancy is not supported during boot-up. Both
management IP addresses must be on the same IP subnet.
* The Release 13.0 user guides incorrectly explain how to format multi-line message text
using “\n” and “\r” in the pre-login-message and motd commands in the
config>system>login-control context. The actual behavior is as follows:

Known Limitations
− “ \n” in the message moves to the beginning of the next line by sending ASCII/UTF-8
characters 0xA (LF) and 0xD (CR) to the client terminal
− “\r” in the message sends the ASCII/UTF-8 character 0xD (CR) to the client terminal
Ingress Multicast • The show mcast-management channel command does not show counts of the replications
Path Management on the ancillary path. [65824]
• Multicast traffic may be affected for ten (10) seconds on a Soft Reset of the ingress card.
[76417]
• Ingress multicast traffic through a queue with multipoint-shared queuing enabled will not
be managed by IMPM when IMPM is enabled on the same ingress complex. [82402]
• Individual MMRP group entries cannot be displayed via CLI. [84252]
DS1/E1 • Via SNMP, a value of zero (0) will be returned for tmnxDS1BERTTotalBits as this function
is not supported on the DS1/E1 CMA. This value is properly shown as “N/A” in the CLI.
[bz1400]
SONET/SDH • On the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-atmoc12/3-sfp, and

m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA, LOP-P defects received by the
MDA/CMA are incorrectly reported as AIS-P events. [8658]
• CV errors are incorrectly being incremented during a Severely Errored Seconds (SES)
state. [29052]
• On the m1-oc192, m4-oc48-sfp and m2-oc48-sfp MDAs, if the H1 and H2 bytes are set to
0xFF but the H3 byte is not set to 0xFF, an AIS-P condition is not reported but an LOP-P
condition is reported. [30498]
• The system does not prevent the user from entering more than fifteen (15) bytes in a path
trace field for ports that have been configured for SDH framing; however, the system will
only use the first fifteen (15) bytes of the entry for the path trace. [99733]
• OC-12c/STM-4c, and OC-48c/STM-16c and OC-192c/STM-64c SONET/SDH interfaces
only run in CRC32 mode. CRC16 mode cannot be configured for these interfaces.
• On the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-atmoc12/3-sfp, and
m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA, only the first 16 bytes of the 62 byte
trace string can be unique for each group of four (4) ports (for example, for ports 1 through
4 or 13 through 16) for ports operating in SONET mode at OC-3. The last 48 bytes of the
trace string will be the same for all ports and will be the last value set. Basically, a unique
trace string per port is not possible if the unique part of the string is longer than 14
characters.
• On the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-atmoc12/3-sfp, and
m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA, the normal range for the
SONET/SDH line signal failure Bit Error Rate (BER) threshold configured using the
config port port-id sonet-sdh threshold command is 3 to 6. For these MDAs and CMA,
the allowed threshold values are 3 to 5. The SNMP variable for this exponential threshold
is tmnxSonetBerSfThreshold.
• The ports on the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-
atmoc12/3-sfp, and m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA are serviced in
groups of four (1-4, 5-8, 9-12, 13-16) by a single framer chip, and as such, all must have

Known Limitations
the same framing across a given group. If framing on one port is changed, all four ports in a
group must be shutdown and the framing will be changed on all four ports.
• The framer on the m4-oc48-sfp and m2-oc48-sfp MDAs supports a single software reset
for all transmit subsystems, so changes to the transmit clock source on a single port will
result in a short traffic interruption on all ports on the MDA. As a result, a short
interruption will be experienced on all ports on the MDA when the transmit clock source
for any one port is changed, for example from line to node timed. Also, traffic will be
interrupted on all ports on the MDA when the port loopback mode on a port also
configured with loop timing are transitioned in any of the following ways:
− from “no loopback” to Internal
− from Internal to “no loopback”
− from Internal to Line
− from Line to Internal.
• Receiving an LOF-E1 error condition on an E1 channel on the c1-choc3-ces-sfp CMA will
cause the system to incorrectly raise an RAI alarm in addition to the expected OOF alarm
on that E1 channel. [114221]
• On the m4-oc48-sfp-b, m16-atmoc3-sfp-b, m4-atmoc12/3-sfp-b and m16-oc12/3-sfp-b
MDAs, a change to the transmit clock source on a port will result in a short interruption on
that port. [119314]
Frame Relay • If several MLFR links are removed rapidly from a bundle, one of the links may be deleted
before it can send a remove-link message. If this occurs, the far-end link will not be
notified and traffic loss may be seen until the far-end link times out and becomes non-
operational. This will not occur if the DS0 group or the T1/E1 interfaces are shut down
first, or if the links are removed a few seconds apart. [75883]
TDM • When a TDM channel is administratively disabled, the alarm statuses from show port are
correct; however, the alarm log “Alarm RAI Set” is only reported when the condition is
cleared. [58505]
PPP • PPP is not preventing IPCP negotiation with a non-matching IP subnet address. [24475]
• For MLPPP network port bundles and bundle-protection groups, PPP keepalive traffic is
shown in the egress network queue statistics, but not in the egress port statistics.
ATM • ATM ports whose operational state toggle at a high rate (faster than both the up and down
hold timers) may remain in a “Link Up” but not be in the operationally Up state. The
workaround is to wait for the hold timer to expire before issuing the no shutdown
command. [35066]
• ATM port statistics for AAL5 packets include all AAL type frames as well as ATM cells
received on L2 ATM pseudowires (Apipes) on the OC-3c/STM-1c and OC-12c/STM-4c
ATM MDAs. This does not apply to an ASAP MDA. [39089]
• If the receive side fiber of an ATM Apipe SAP loses link and that Apipe is also bound to an
SDP, then remote OAM cells received on that SDP will be dropped since the Apipe service
is locally in a down state. Additionally, ETE-RDI cells will be transmitted out the ATM
SAP to the CE. [39571]

Known Limitations
• On the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs (and not an ASAP MDA), ATM
Apipes configured with a vc-type of atm-vpc drop all ATM OAM F4 segment cells and
pass through the ATM OAM F4 end-to-end cells. The PTI field of the forwarded ATM
OAM F4 end-to-end cells is set to five and might cause interoperability issues if the third-
party equipment expects the PTI field to be zero. [40451]
• Bi-directional FR PVC management procedures over an ATM VC part of an FRF.5 VLL
are not supported. When doing FRF.5 interworking between different models of SR/ESS or
other products, the bi-directional network PVC management over the ATM VC must be
disabled on the other products. [49696]
• If traffic is passing on an ATM OC-12 port and the port speed is changed to OC-3,
“Unknown Protocol Discards” may be seen at the console although no such frames are
actually being received. The OC-3 port's operational state is not affected, although some
noise may be interpreted as end-to-end VC-RDI/AIS cells by newly configured ATM
PVCs, which would cause those PVCs to go operationally down. The condition will clear
as soon as ATM traffic passes once again through the port. [58197]
• ATM cells in a VPC connection with the GFC field not equal to zero will be discarded.
This only affects non-ASAP ATM MDAs. [75387]
• See SONET/SDH in the Known Limitations section for additional limitations that affect
ATM MDAs.
• On the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs (not the ASAP MDAs), some
ingress traffic counters do not update for certain types of ATM OAM F5 cells. This results
in discrepancies between the ingress traffic statistics: PVC vs. port vs. SAP, packets vs.
octets. Egress traffic is not affected. [109427]
ATM MDAs Access • The ATM interfaces on non-ASAP MDAs listed below only support the customer-facing
Mode Only access mode.
Table 38. ATM MDAs that Support Access Mode Only

3HE05944AA 16-port ATM OC-3c/STM-1c MDA – SFP Rev B
3HE05945AA 4-port ATM OC-12c/STM-4c MDA – SFP Rev B
See ASAP for more information about the ASAP MDA.
ATM and IS-IS • IS-IS is not supported on IES and VPRN interfaces with ATM PVC SAPs in this software
release.
ATM Traffic The following limitations only apply to the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs
Management/ and do not apply to the ASAP MDAs.
Statistics • In the context of multiple services using an ATM MDA, the following two criteria must be
Limitations met in order to satisfy the QoS guarantees:
− VC fairness

Known Limitations
− COS fairness
• VC fairness implies that each VC gets its due share of bandwidth relative to the other VCs
and COS fairness implies that within each VC, each COS gets its due share of bandwidth.
What is considered the “due share” is very specific to the configuration. (For example, for
two VCs of the same ATM service category, the due share will be proportionate to the
configured rates of the VCs; for two VCs with different ATM service categories, the due
share will depend on the priority of the service category and the configured rate, and so on.)
• A minor loss of throughput (< 2% of line rate) may occur if an OC-12 port is configured
with small number of shaped PVCs, the difference in the configured ATM rates of the
PVCs is large, and the sum of the shaped rates is equal to port rate. The loss of packet
throughput occurs in the highest traffic parameter VC and only. [28869]
• The ATM layer shaping in the MDA schedules cells of the high-priority Forwarding Class
queues with strict priority over cells of low-priority Forwarding Class queues within a SAP.
This is performed such that packet delay and jitter are minimized on the high-priority
forwarding class queues. As a result in some traffic loading scenarios, the lower priority
forwarding class queues may not achieve their fair share of bandwidth. This is the case
when the high-priority Forwarding Class queues have an offered traffic to the ATM MDA
per-VC queue equal or higher than the PIR of the ATM VC. The user can alter this
behavior and trade delay performance for forwarding class fairness in this specific scenario
configuring H-QoS schedulers to limit the total offered load out of the forwarding class
queues to the ATM MDA per-VC queue to the PIR of the ATM VC. [30819]
• OC-12/STM-4 latency increases when applying a new ingress SAP policy that adds more
queues. The latency increases from around 22.2 ms to 24.8 ms over a 1 min period. Traffic
loss does not occur during this period.
• Port input statistics do not increase when terminating e-t-e AIS cells are received.
• PVC admin state is not applicable. There is no command that can administratively disable a
PVC; in order to disable a PVC, the user must disable the applicable service or service
interface.
Class of Service • The following limitation only applies to the OC-3c/STM-1c and OC-12c/STM-4c ATM
Fairness Affected MDAs, and do not apply to the ASAP MDAs.
on Shaped VCs In the case of ATM VCs configured with more than two classes of service where one
queue, queue A, is allowed no burst beyond CIR and another queue of the same priority,
queue B, is allowed to burst up to line-rate; the traffic offered to queue B might prevent
queue A from achieving its CIR. The problem has a lesser degree of impact if there is an
increased number of ATM VCs on the port and can also be addressed by lowering the con-
figured PIR of queue B. [35224]
ASAP • Following is a list of limitations for the 4/12-port Channelized DS3 MDA, the 1-port
Channelized OC-12/STM-4 (DS0) and the 4-port Channelized OC-3/STM-1 (DS0) ASAP
MDA:
− BERT pattern 2e20 is not supported.
− ATM ILMI support is not enabled.
− IPv6 is supported for network mode PPP channels and access mode PPP, FR and
cHDLC channels and MLPPP bundles.

Known Limitations
• In exceptional cases, especially in a fully loaded node, where the occurrence of a High-
Availability CPM or CFM switchover is exactly concurrent with an APS switch from
Working to Protect (both unidirectional or bi-directional failures), PSBF may potentially be
posted by the far-end node during the APS K1/K2 byte exchange due to the increase
latency response of the near-end where the CPM or CFM switchover is occurring. [41192]
• DS3 configuration with m23 framing on the channelized ASAP MDA may detect false
AIS. This may cause the DS3 to bounce occasionally. [74671]
VSM-CCA • The rates in a network-policy applied to a VSM-CCA or VSM-CCA-XP MDA are based
on 20 Gb/s rather than 10 Gb/s. For example, if a network-queue policy with rate of 1% is
applied to VSM-CCA or VSM-CCA-XP, the actual rate will be 20 Gb/s x 1% = 200 Mbps.
If the same network-policy is applied to an Ethernet mda, the actual rate will be 10 G x 1%
= 100 Mbps. [39134]
• Multiple data streams on the same path with the same priority, for example a stream on
Path A SAP-SAP and another stream on Path A SAP-net with normal priority, do not get
equal bandwidth if a path or aggregate shaper rate is configured on the CCA. The variance
can be up to 10% for these like streams. [40347]
• The VSM-CCA/VSM-CCA-XP only provides ifInUcastPkts, ifInOctets, ifOutUcastPkts
and ifOutOctets counters. The VSM-CCA/VSM-CCA-XP does not distinguish between
unicast, multicast and broadcast packets. As a result, IP multicast statistics are also not
supported on a VSM-CCA/VSM-CCA-XP IP interface. [40551]
• When there is multipoint (broadcast, unknown, multicast) traffic and a CPM switchover
occurs, the multipoint traffic can cause overloading of the fabric link which then generates
backpressure to cause ingress packets to be dropped. When this occurs, there is currently
no means of displaying where the packets are dropped using show commands available on
the system. [40609]
SNMP • After an SNMP log is removed and recreated, traps will no longer be sent to a trap-target
Infrastructure that has the replay option configured. To start sending traps again, the trap-target should
be removed and recreated. [162559]
LAG • A failure of the link holding the primary port of the LAG can sometimes very briefly
impact (<10e-4 seconds) flows on other links of the same LAG. This is not the case for
failures on other links (non-primary) of a LAG. [49698]
• The IOM3-XP/IMM LAG and ECMP ingress conversation hashing algorithm is different
from the one used on IOM-20g-b and IOM2-20g due to hardware differences in the ingress
forwarding plane. While both versions of the hashing algorithm are effective at distributing
conversation flows over multiple egress paths, when used in conjunction with the same
system in some configurations, a non-optimal distribution may occur. For example, when a
series of systems (for example, system A, B, C) are each hashing the same packet flow over
an equal number of paths for each system, and each system is using the same distribution
algorithm, the conversation flow distribution will be the same for each system relative to
the available paths. If on the intermediate system (B), the flows ingress on both an IOM3-
XP/IMM and an IOM-20g-b or IOM2-20g, different algorithms will be used to determine
the egress paths to the next system (C) and may result in some egress paths having more
flows than the others. [72557]

Known Limitations
• When lag-per-link-hash or lag-link-map-profile is used for a given SAP or network

interface egress traffic, sub-second OAM traffic generated by the router (if supported for a
given service/network interface) may not follow the same link as the data path traffic.
• When lag-per-link-hash or lag-link-map-profile is used for a given SAP or network
interface egress traffic and BFD is enabled on that interface, BFD packets remain round-
robin over the active links of the LAG irrespective of which link is used on egress by the
given SAP/network interface.
• On a LAG, CPM-originated sub-second CFM/BFD packets use hashing independent of that
configured for the data traffic. When per-fp-egr-queuing is enabled, the CFM/BFD
packets may egress LAG over a different port than used by the SAP’s data traffic. For those
CFM/BFD packets, internal system queues, instead of the SAP’s queues are used, and
CFM/BFD packets are not accounted for in the SAP queues.
• Pulling out the active CPM/CFM can, in rare cases, result in LACP to signal to adjacent
nodes that ports are going down. To avoid this and other potential issues, Alcatel-Lucent
strongly recommends always pressing the RESET button before pulling out a CPM/CFM
card. [146453]
• Access-egress queue optimization feature per-fp-egr-queuing is not supported on the
same LAG with BFD. However, this restriction is not enforced. If BFD is erroneously
enabled, BFD packets may use a different LAG port than the egress LAG port used for data
traffic, and if the port is oversubscribed, the BFD packets may starve and lead to the BFD
session going down. [155303]
• When BFD is to be originated/terminated in a SAP context on a given LAG with per-fp-
sap-instance enabled, Alcatel-Lucent recommends using, at minimum, a one-second (1 s)
interval timer. Very large SAP scales on LAG may require even larger timer values,
especially on older SR OS system. Failure to do so may result in BFD sessions going
operationally down during LAG-member-port status changes. [170148]
• Multicast CAC supports up to eight (8) levels per LAG; thus, the operator cannot define
different levels for every possible LAG port count when LAG contains more than eight (8)
member ports. [175567]
• PW-SAP on distributed mode LAG with Vport is not supported. [178343]
• For mixed-speed LAG member port support, ingress-rate and egress-rate for LAG member
ports must be set to default.
MLPPP • If several PPP member links in a MLPPP bundle are removed or shut down at the channel-
group level simultaneously, term-requests may not be sent out. In this event, the far-end
links may not be notified and the links may not become non-operational until PPP keep-
alives fail. To work around this issue, shut down member links at the physical level first (if
possible), or remove links or shut down channel groups one at a time. [87044]
• IPv6 interfaces over MLPPP bundles are only supported on ASAP MDAs even though the
system allows that configuration on other MDA/CMA types. [143700]
APS • Ports that are part of an MLFR bundle or that contain an MFLR bundle cannot be APS
protected.
• APS is not supported on MDAs/CMAs that support LAN and WAN-PHY mode for 10G
ports (for example, m2-10gb-xp-xfp).
• The imm1-oc768-tun card does not support APS.

Known Limitations
• When an APS group contains circuits on separate ATM MDAs, both MDAs must be in the
same ATM mode (max8k-vc|max16k-vc).
• Annex B (of ITU.T G.841) is supported in the following scenarios:
− Supported with single chassis APS (SC-APS) only (no MC-APS support)
− Supported on all 7750 SR/ and 7450 ESS platforms and with all IOM types.
• A mirror/LI destination SAP cannot be on an APS protected port.
• Restrictions specific to SC-APS:
− Bundles are not supported on ports (or contain ports) that are protected with uni-
directional SC-APS.
− Uni-1plus1 SC-APS is supported only on the 7750 SR-c4/c12 platforms. Only the
following cases are supported:
− POS ports on non-channelized MDAs configured in network mode
− CES ports configured in access mode where only Cpipe services (SAPs) are
configured on that port.
− ASAP channelized ports with MLPPP where the ports are configured in network
mode.
• Restrictions specific to MC-APS:
− Network mode ports cannot be part of an MC-APS group.
− Ipipe SAP cannot be on a port that is part of an MC-APS group.
− Routing protocols cannot be run over MC-APS protected ports (however, static
routing is allowed).
− BFD and VRRP over MC-APS protected ports are not supported.
− The only type of bundle that can be bi-directional MC-APS protected is MLPPP with
IPCP encapsulation (on ports configured in access mode).
− Ports with Frame Relay (FR) or Cisco HDLC encapsulation cannot be protected with
MC-APS.
− Only bi-directional mode is supported with MC-APS. The uni-directional and
uni-1plus1 modes are not supported.
• In some cases of RDI-L, the transmitted K1/K2 bytes on the wire may differ from those
maintained by the CPM or CFM's APS controller (as displayed in CLI). [36537]
TCP • It is not possible to delete an authentication keychain if that keychain was recently removed
Authentication from a BGP neighbor while BGP was operationally down. BGP has to become
Extension operationally active before the keychain can be deleted. [57277]
Routing • Setting a metric of zero in OSPF or IS-IS is not supported and causes the interface to fall
back to the reference-bandwidth computed value instead of setting the value to zero.
[17488]
• Routes exported from one protocol to another are redistributed with only the first ECMP
next-hop. Therefore, if BGP routes having multiple next-hops are exported to a VPRN
client, only one next-hop for the route will be exported. The one chosen is the lowest IP
address of the next-hop address list. [40147]

Known Limitations
• A static route with a CPE connectivity target IP address which is part of the subnet of the
static route itself will not come up if there is no alternate route available in the routing table
which resolves the target IP address. This is because a static route can only be activated if
the linked CPE session is up, and in this case the CPE session can only come up if the static
route itself is activated. [62663]
• Policy-statement entry from interface interface-name can only be used with multicast
routing and will not match other routing protocols. To achieve a similar match for other
routing protocols, from protocol direct with a prefix-list should be used. [89371]
• When the applied export policy is changed in conjunction with an export-limit, it may not
take effect immediately without clearing the policy (no export/export), or in very few
cases, toggling the administrative state of the protocol. [90244]
• There is no warning trap sent after a clear export policy is issued when the export-limit is
increased a few times and clear export is performed. [90274]
• Using no preference in the routing policy does not trigger re-evaluation of routes that are
being leaked from another local VRF. The workaround is to set the preference with the
desired value in the policy. [114322]
• Static routes do not take an IPv6 Anycast address as next-hop. [115800]
• If the chassis mode is changed from chassis mode A, B or C to chassis mode D
dynamically, and the ECMP parameter changed to a value greater than 16, the maximum
number of ECMP next-hops will not be automatically refreshed to populate additional
ECMP next-hops. This will only occur if the route is updated via some other mechanism
such as a resetting of the routing adjacency, peering, or a new route update, causing an
IOM refresh of the route’s next-hop information.
• The LFA next-hop may use the same egress interface as the primary next-hop when a mix
of IES spoke-SDP interfaces and network interfaces is present. [141276]
• uRPF and interface statistics may not be correct after an event such as a clear statistics,
clear card or switchover. [150500]
• If the triggered-policy command is enabled, in order for route policies to take effect after a
High-Availability switchover, clear commands must be executed or the triggered-policy
configuration toggled (shutdown/no shutdown). [154937]
• IP options 131 (Loose Source and Record Route) and 137 (Strict Source and Record Route)
are not processed. Destination-based routing will be performed on the IP packets
containing these options. [167864]
• A clear of the uRPF statistics should only be performed when uRPF is enabled for IPv4
and IPv6. If not, the counters may not reset to zero (0). [174961]
IP/RTM • The traffic sent to non-subsuming routes of an aggregate route with an indirect next-hop
address to be resolved by a VPN-leaked route will be blackholed. [149804]
Routing Policies • In a routing policy configuration that exports routes into IS-IS, the statement to level sets
the level of the route and is not a match criteria. However, if an incompatible level is
specified or the destination protocol is not IS-IS, then no match is returned and policy
evaluation stops. For example, if the router is configured as L1 only and to level 2 is
specified, then policy evaluation stops and will not evaluate subsequent entries.

Known Limitations
On the router redistributing the BGP routes into IS-IS, an IS-IS export policy containing
two entries is applied. The first entry matches, except for the to level 2 statement because
the router is configured as L1 only. The second entry is a full match. Both entries have an
action accept statement, so the BGP-learned routes should be redistributed into IS-IS (by
entry 2). However, due to the behavior outlined above, this does not happen and no routes
are exported from BGP into IS-IS.
To avoid this condition, the correct IS-IS level should be set or the statement should be
omitted. Alternatively, an entry with a to level statement should be placed at the end of a
policy. [171345]
• Policies using the action next-entry do not operate as expected when the following
condition is true: a route-policy statement with two (2) entries, for which some routes
match the first entry but not the second one. If the action in the first entry is next-entry, the
action of the second entry will be irrelevant since the routes do not match. One might
expect that the routes would be processed as configured in the default action of the policy.
However, they will behave as the default action of the protocol to which the policy is
applied. [173046]
IPv6 • When debug router ip packet is enabled, packets received on a 6-over-4 tunnel do not
display the IPv4 header information and packets sent on the tunnel do not display the IPv6
header information as the encapsulation and decapsulation is performed on the line card.
[45606]
• The following restrictions apply for IPv6 support for HTTP-redirect:
− no support for ESM Wholesale/Retail
− no support for one-time HTTP redirect
− no support for ESM credit-control IPv6 filters
− ingress only
DHCP • If the addition of the Option 82 information to a DHCP packet would cause the maximum
size of 1500 bytes to be exceeded, the DHCP Relay incorrectly does not forward the
original DHCP packet (without the additional Option 82 information). [37061]
• A Local User Database (LUDB) cannot be applied to the DHCPv6 Local Server used for
ESM.
• From Release 11.0.R1 onwards, PPPoX leases are no longer persistent (stored on Compact
Flash) in an SR OS-based DHCPv4 server. [148366]
• A DHCP server using failover-per-pool is not allowed to synchronize with a DHCP server
using failover-per-server. [169222]
• A DHCPv6 server in SR OS only accepts relayed messages (Relay-forward).
• DHCPv6 Relay-Forward messages received on an IPv6 interface that connects to a
DHCPv6 client will be delivered to the DHCPv6 server in the following scenarios:
− a single Lightweight DHCPv6 Relay Agent (LDRA) in front of an ESM subscriber
interface
− DHCPv6 Relay Agents in front of an ESM subscriber interface with DHCPv6
snooping enabled at the group-interface. A combination of LDRA and DHCPv6
Relay Agents is supported with a maximum of five.
The following examples are not supported:

Known Limitations
− an LDRA in front of a regular (non-ESM) IPv6 interface

− a DHCPv6 Relay Agent in front of a regular (non-ESM) IPv6 interface
− a DHCPv6 Relay Agent in front of an ESM subscriber interface with DHCPv6
snooping disabled at the group-interface
• A forceRenew message from a DHCP server, located in the same VRF as the DHCP Relay,
is sent as a unicast message to the client’s IP address. The source address of the
forceRenew is the actual DHCP server IP address while it should be the one configured as
siaddr-override address. [212028]
RIP • The RIP global statistics for all RIP instances is incorrectly being displayed for each VPRN
instance. This has the effect of causing one to think that the VPRN instance has learned
routes when in fact it has not. [26472]
• When 16 bytes of authentication-key was configured in RIP, the last byte was filled with
the null character in Release 10.0 and Release 11.0 prior to 11.0.R6. Interoperability issues
would arise when the network consisted of SR OS routers running these older releases and
those running 11.0.R6 or higher. [167905]
IS-IS • ECMP across multiple-instances is not supported. ECMP is per instance only. Only one
route, the one with the lowest instance ID, is installed. [85326]
• In a multi-instance IS-IS configuration, the same IS-IS prefix is not leaked to all instances
with Level-1 and Level-2 leaking. Leaking between instances is configured with routing
policies. [85463]
• There is no separate export-limit configuration for IPv6 in IS-IS. The same export-limit is
used for IPv4 and IPv6 routes depending on the policy configuration. [91520]
• IP Fast Reroute (FRR) does not guarantee low loss when multiple interfaces are going
down; it is limited to first-order failures where loop-free forwarding as a property continues
to hold. It is possible that the loss is low because all down events are detected before the
first IGP SPF runs, and, the updated topology does not result in a loop. Alcatel-Lucent
recommends against depending on FRR in such topologies.
SR OS defaults to one (1) next-hop only in ECMP scenarios. In cases where ECMP paths
exist, it is possible that the IGP chooses an Loop Free Alternative (LFA) that is different
from any of the ECMP paths. While the FRR switch itself is (nearly) hitless, the subsequent
IGP SPF-based next-hop update will pick one of the remaining ECMP paths as the primary
next-hop. A change in the primary next-hop that is not the same as the previously com-
puted LFA can result in transient forwarding loops, based on the updated topology. This
could be especially amplified if the SPF timers are different, or if the routers in the network
are heterogeneous (different vendors, different route processor speeds/capability).
Note that the same sequence of convergence events can occur, even if ECMP > 1 is config-
ured, as long as there are more than MaxECMP paths available; the next-hop count of one
(1) is a special case of the same. [130305]
• When the LFA next-hop for a far-end GRE tunnel is activated, packets of a spoke-interface
do not benefit from IP FRR but wait until the SPF has updated the new primary next-hop
for the GRE SDP far-end before resuming forwarding. [130913]
• IP FRR degrades to regular convergence when IS-IS is the DR on a broadcast interface and
the failure is a interface shutdown. As such, Alcatel-Lucent recommends a P2P
configuration. [138279]

Known Limitations
• In a network with a VPRN PE node redistributing BGP-VPN routes into IS-IS and an IS-IS
level-1/2-capable CE router in the connected IS-IS network leaking these routes from
level-1 to level-2 could result in a routing loop when the PE receives the level-2 route and
replaces the BGP-VPN route with it so that it is no longer exported. A workaround is to tag
all BGP-VPN routes that are exported to IS-IS and to block all tagged IS-IS routes from
getting redistributed in level-2 on all level-1/2-capable CE nodes. [168803]
• ICMP-Tunneling (config>router>icmp>tunneling) is not supported with segment-routing
tunnels. [200641]
OSPF • The system may refresh self-originated LSA shortly after completing a CPM or CFM
switchover which may mean the entry is refreshed before the expiration of the age-out
period. [65195]
• An SR OS router with more than one point-to-point adjacencies to another router over links
of equal metric, may compute the shortest-path tree over the incorrect link in the case of
unidirectional link failures on the far-end router. This condition lasts until the dead timer
expires and the adjacency over the broken link is brought down locally (near-end). A
workaround is to change to broadcast interfaces or enable BFD on these routers. [79495]
• During High Availability switchover, more than the configured export-limit routes get
leaked when exporting to OSPF. Once the High-Availability switchover is completed,
routes will come back as restricted by export-limit. [90098]
• The export limit will not show the export-count after route summarization; it only displays
the routes exported before summarization. If the routes have not been advertised due to an
OSPF external-db-overflow condition, the export-limit count will still count the routes as
exported. [91520]
• When export limit is reduced via the export-limit command, toggling the administrative
state of the protocol is required to remove all previously exported routes. [91520]
• ICMP-Tunneling (config>router>icmp>tunneling) is not supported with segment-routing
tunnels. [200641]
OSPF PE-CE • OSPF traffic engineering is not supported in VPRN instances.
BGP • If BGP transitions to the operationally disabled state, the clear router bgp protocol
command will not clear this state. The BGP protocol administrative state must be
shutdown/no shutdown to clear this condition. [12074]
• If a 6PE prefix is received with two or more labels for the same next-hop, the reference
count in the show router bgp next-hop output will always show a value of one (1).
[56638]
• The system does not prevent the user from using the same IP address of a BGP peer on one
of the router interfaces and configuring this can result in a configuration that fails to
execute after a reboot. [57198]
• If the BGP neighbor address is configured prior to configuring that same IP address on a
router interface, the configuration can be saved and loads properly with a warning message
displayed. Also, the peering shows up as idle. The workaround is to not use the same IP
address for a local router interface and a BGP neighbor. [85198, 132818]

Known Limitations
• In a typical PE-CE scenario, when the PE is learning IPv6 routes from multiple CEs over a
BGPv4 session, the traffic switchover time for IPv6 with BGP EDGE PIC may not be sub-
100ms. To achieve this, a BGPv6 session protected by BFDv6 may be required to learn
IPv6 prefixes. [122822]
• The BGP best route selected may change after two High-Availability switchovers when the
ignore-router-id option is configured in the bgp best-path-selection context. [130406]
• When local-as is configured at the peer/group level, a set/reset of local-as at a higher level
may cause the BGP session to flap. When peer-as is configured on the peer level, a
set/reset peer-as on the group level will cause the BGP session to flap. [148704]
• If filter policy resources are not available for newly auto-generated address prefixes when a
BGP configuration changes, new address-prefixes will not be added to impacted match
lists or filter policies as applicable. The operator must free resources and change the filter
policy configuration, or the BGP configuration must be changed to recover from this
failure.
• Inter-AS Option B and C are not supported between a confederation’s member ASes.
[157071]
• For Inter-AS Option C, BGP-3107 routes are installed into unicast RTM (rtable-u). Unless
routes are installed by some other means into multicast RTM (rtable-m), Option C will not
build core MDTs; therefore, rpf-table should be configured to rtable-u or both.
• When update-fault-tolerance is disabled, in some cases where the length of the
aggregator, aspath, as4_aggr, as4_path attribute is wrong, an invalid-update log-event is
generated. [157817]
• The clear router bgp protocol command cannot be used to trigger BGP graceful restart
(GR). It will clear the BGP routes before entering the helper mode. The proper way to
trigger GR is to use the clear router bgp neighbor x.x.x.x command. [159793]
• If an SR OS node has negotiated graceful restart (GR) notification with a BGP peer and it
detects a hold-timer expiry event, it will incorrectly display “hold timer expiry” instead of
“send notification” as a reason for entering the GR helper mode in the debug router bgp
graceful-restart output log. [161274]
• When update-fault-tolerance is enabled and all attribute length fields are okay, the peer is
brought down when the mpreach/mpunreach attribute cannot be correctly parsed. [161501]
• BGP sessions must be reset/toggled after deleting the Anycast interface in order to change
the label usage range from 256K to 512K. [184237]
• The “Last Modified” timestamp in the show router bgp route detail/hunt output can have
the wrong value after a dual CPM/CFM switch over. [188240]
• When next-hop-resolution use-bgp-routes is configured, if shortcut-tunnel is configured
with disallow-igp option, BGP routes do not get resolved over another BGP route.
• When the LFA backup of a BGP next-hop of a prefix is a tunnel (IGP shortcut), traffic to
the BGP prefix does not benefit from IP Fast Reroute (FRR). It is dropped until the IGP
SPF has updated the route for the BGP next-hop. [211564]
BGP-EVPN • CPM4 or higher is recommended in routers with a significant number of BGP-EVPN

services and/or routes. [228062]

Known Limitations
BGP VPWS • If a multi-homing PE receives a BGP-VPWS NLRI with the D-bit set or the CSV set from
a remote PE, it will not cause the BGP-MH site within the service to go operationally down
(and will subsequently cause a BGP-MH DF switchover). An example of this is if the
remote PE shuts down the SDP connected to the multi-homing PE; this will not cause a DF
switchover on the multi-homing PE. In order to achieve a DF switchover in this case, some
kind of continuity check between the two nodes will be required (for example, SDP
keepalives). However, network failures that cause the network PW on the multi-homing PE
to go operationally down will cause a DF switchover. [147804]
• If a BGP update for a VPWS service is received with a Circuit Status Vector (CSV) length
field of greater than 32 bits, it will be ignored and not reflected to BGP neighbors. If a BGP
update for a VPWS service is received with a CSV length field of greater than 800 bits, a
notification message will be sent and the BGP session will restart. BGP VPWS services
support a single access circuit; consequently, only the most significant bit of the CSV is
used on transmit. On receive, for designated forwarder selection purposes, only the most
significant byte of the CSV is examined.
MPLS/RSVP • The no rsvp command in the config>router context has no effect as the state of RSVP is
tied to the MPLS instance. The no mpls command deletes both the MPLS and RSVP
protocol instances. [8611]
• An invalid Class Number or C-Type in the Session Object does not cause a PATH Error
message to be generated. [12748]
• To disable OSPF-TE on a link, both ends of the link should be MPLS/RSVP-disabled for
CSPF to work correctly and be removed from the TE database. [15127]
• The bandwidth parameter is not supported on PATH and RESV messages of one-to-one
detour and facility-bypass paths. [27394, 57847]
• For (rare) topologies in which the protected LSP and the detours are set up along parallel
links across several hops (link protection only), Fast Reroute (FRR) may take longer to
restore traffic if the primary path is broken. [39808]
• Shutting down a port on an OC-3c/STM-1c MDA may not provide sub-50 ms failover for
an RSVP path signaled over that port. This issue does not occur if the fiber is disconnected
or if the path is shut down. [39973]
• Fast failover times of less than 100 ms cannot be achieved for Fast Reroute (FRR)
protected LSPs if the failed link is detected by copper Ethernet SFPs. Sub-second failover
times are achieved, but the failover times with copper Ethernet SFPs are inherently longer
based on how the system communicates with the SFP. [49003].
• A manual-bypass tunnel that terminates on the incoming interface IP address at the merge
point will become operational but will not be properly associated with the primary LSP.
The recommendation is to always use the IP address of the system interface to ensure
reachability to the node. [59184]
• 7750 SR-c4/c12 RSVP LSPs cannot be signaled over a channelized DS1 or E1 interface if
the channel group bandwidth is less than 1 Mbps. [59776]
• There are scenarios where the bypass optimization does not ensure that a node-protect
manual bypass will be selected over a node-protect dynamic bypass tunnel. This is because
the manual bypass may be unavailable when the association of a bypass LSP is made with
the primary LSP.

Known Limitations
The bypass optimization feature only changes the association for an LSP which requested
node protection but is currently associated with a link-protect bypass.
To ensure this selection when using manual bypass, dynamic bypass must explicitly be dis-
abled. [60261]
• If a local IP address is configured with the same address as the destination address of an
MPLS LSP, the LSP will no longer be set up and will use the RSVP error code of
“routingError”. [73326]
• Least-fill behavior is not exhibited when the user does a configuration change MBB by
decreasing the bandwidth on the LSP. [74544]
• In case of a non-CSPF LSP with only secondary paths, once the active secondary path goes
down, the LSP will wait for the regular retry time. It will then try to set up again, and if that
fails with a path error, it will go into fast-retry mode. [80012]
• On the leaf node of a P2MP LSP, the DSCP value of an IP packet will not be used for
classification even though the ler-use-dscp option is configured in the network policy. The
LSP EXP from the MPLS header will be used instead. The workaround is to not configure
the ler-use-dscp flag on the network policy. [80105]
• Refresh reduction over inter-area manual bypass will only work if the RESV RRO format
at the bypass destination is one of the following: IL, SLIL, SLI or SIL. [108420]
• For an LSP terminating or passing through a router where the OSPF router ID is different
than the system interface, the AR hop table entry will be incorrect. [109589]
• If route recording is not enabled on manual bypass or the system interface is not recorded
in RRO manual bypass, association of inter-area manual bypass to protected LSP may not
work correctly. There may be an incorrect AR hop table entry when the OSPF router ID is
different from system interface. Inter-area manual bypass association does work correctly
for the following supported RESV RRO formats for the primary LSP path: SLIL, ILSL,
SIL, SLI, ISL and SL.
− S: RRO object with system ID
− I: RRO object with interface ID
− L: RRO label object
If no node supports any of the formats above, the bypass LSP association to protect LSP
may be incorrect. [109753]
• A manual bypass LSP may not come up if the user specifies a local interface address of a
node in the exclude-node configuration of that LSP. When computing the CSPF path at the
ingress (LER) or transit LSR (ABR), if the local interface is down or not part of the IGP or
not in the same area as the node doing the CSPF computation, MPLS will be unable to
resolve the interface address to its router ID and CSPF may not compute a path excluding
the node specified by the user. [118046]
• MPLS-TP is only supported on static LSPs and static PWs.
• MPLS-TP LSPs can only carry static MPLS-TP PWs, while MPLS-TP PWs can be carried
on static MPLS-TP LSPs or dynamic RSVP-TE LSPs.
• CAC is not supported for MPLS-TP LSPs or PWs.
• SVC-Ping and SDP-ping are not supported on MPLS-TP LSPs and PWs.
• Dynamic bypass LSP re-optimization does not support inter-area bypass LSP and P2MP
LSP.

Known Limitations
• Inter-area dynamic bypass LSP and bypass LSP protecting S2L paths of a P2MP LSP are
not supported.
• GMPLS LSPs are only supported on 10GE and 100GE ports.
• Penalty weights have no impact on backup LSP paths that are forced to be strictly SRLG
diverse from the primary. That would be the case of secondary LSP paths and bypass
backup LSP with the srlg-frr strict option enabled. When SRLG groups are changed on an
MPLS interface on a node, this information is reflected on all other nodes, which have TE
enabled and on which the IGP is not in administratively down state. Depending on the
number of SRLG groups added or removed from an MPLS Interface, the expected results
may not be immediately visible if SRLG groups are changed on-the-fly.
• An inter-area RSVP LSP with Fast Reroute (FRR) enabled or disabled but with the PATH
message not containing the RRO may fail at an ABR with a failure code of “routingLoop”.
• A pre-empting LSR will perform hard pre-emption, instead of soft pre-emption if the PATH
message of an LSP did not include the RRO.
• LSP BFD cannot be configured on RSVP LSP secondary paths.
MPLS-TP • static-dynamic pseudowire switching for MPLS-TP is only supported when the dynamic
PW segment is a spoke-SDP using the PW ID FEC.
LDP • If triggered-policy is configured, LDP policies are not dynamically evaluated for changes
in FECs. [71830]
• It is not possible to apply an accounting policy in the egress LDP statistics context if both
default and record combined-ldp-lsp-egress are configured in that policy. [84406]
• When enabling or disabling the ldp-shortcut option in the global routing context, any
indirect LDP static-route will be operationally toggled and its age will be reset. [85366]
• A GRE SDP will stay operationally down in case the SDP far-end address resolves through
an LDP or RSVP tunnel due to configured shortcuts. GRE tunnels cannot be established
over MPLS tunnels. [92314]
• clear router ldp instance is not an atomic operation — it consists of shutdown followed
by no shutdown. If a High-Availability switchover happens right after the clear command,
the no shutdown part of the command might have been lost during the switchover,
resulting in the LDP instance remaining shut down on the newly active CPM/CFM. After
the switchover, the user can issue a no shutdown on the LDP instance to re-enable LDP.
[160940]
LDP IPv6 • The PW switching feature is not supported with LDP IPv6 control plane. As a result, the
CLI will not allow the user to enable the vc-switching option whenever one or both spoke-
SDPs use an SDP which has either far-end or tunnel-far-end configured as an IPv6
address.
• Layer-2 services that use the BGP control plane (such as dynamic MS-PW, BGP-AD
VPLS, BGP-VPLS, BGP-VPWS, and EVPN MPLS) cannot bind to an IPv6 LDP LSP
because a BGP session to a BGP IPv6 peer will not support advertising an IPv6 next-hop
for the Layer-2 NLRI. These services will not auto-generate SDPs using LDP IPv6 FEC. In
addition, they will skip any provisioned SDP with either far-end or tunnel-far-end
configured to an IPv6 address SDP when the use-provisioned-sdp option is enabled.

Known Limitations
• Multi-homing with T-LDP active/standby FEC 128 spoke-SDP using LDP IPv6 LSP to a
VPLS/B-VPLS instance is supported. BGP multi-homing is not supported because BGP
IPv6 does not support signaling an IPv6 next-hop for the L2 NLRI. The Shortest Path
Bridging (SPB) features will work with spoke-SDPs bound to an SDP which uses an LDP
IPv6 FEC.
• Resolution of IPv6 or IPv4 FECs over an IPv6 T-LDP session tunneled over an RSVP IPv4
LSP is not supported.
IP Multicast and • The Router Alert IP option is not included in mtrace queries that are unicast to the last-hop
MVPN router in the trace as defined by the IETF draft. Note that this causes no known
interoperability issues since this packet is still destined for an IP address on this last-hop
router. [37923]
• (S,G) or (*,G) multicast streams transmitted through an LAG will no longer be hashed on
the UDP source or destination ports; identical streams with differing UDP ports will all
transit over the same link. [66618]
• When a multicast CAC (MCAC) policy is applied under IGMP-snooping of a SAP with
static-groups that are configured in the bundle of the same MCAC policy, the bandwidth
used by the static groups on the SAP is not recalculated after the bundle is disabled and re-
enabled. The used bandwidth remains at zero for the static groups. In addition, the MCAC
recalculation command tools perform service id id mcac sap sap recalc policy policy
fails to recalculate the used bandwidth, and the use of the bundle option in the command
returns an error. [71023]
• IGMP-snooping and multi-chassis synchronization (MCS) may not work correctly with all
combinations of default and outer Q-tag only values in case of QinQ SAPs. For proper
operation, one of the following must be true:
− MCS is configured with a sync-tag for the entire port
− The IGMP-snooping SAP and the MCS sync-tag must be provisioned with the same
Q-tag values. [102473]
• When MoFRR for PIM is enabled, tunnel interfaces (for example, dynamic in-band mLDP
interfaces) are ignored for MoFRR functionality.
• Some multicast limits (for example, the number of OIFs per IIF per line card) are not
enforced by the system; thus, Alcatel-Lucent recommends that operators verify with
Alcatel-Lucent support teams that planned deployment limits are supported.
• RPF Vector must be enabled on every router for RFC 6037 MVPN inter-AS option B/C.
Failure to do so will result in RPF Vector being dropped and result in PIM Join/Prune
processing as if RPF Vector was not present.
• Packets arriving on the standby interface that belong to a standby stream for a given (S,G)
will be discarded and counted as either discards or mismatch against the (S,G) record. If the
standby interface and the RP interface are identical, then a discard counter is incremented.
If the standby interface differs from the RP interface or the RP interface is NULL, then a
mismatch counter is incremented.
• MoFRR active joins are untouched when periodic mc-ecmp-balance rebalancing is active
to prevent traffic impact.
• Deploying the sender-only/receiver-only feature requires all PE nodes in an ng-MVPN
using RSVP P-tunnels to use SR OS Release 11.0.R1 or newer. [154000]

Known Limitations
• When dynamic mLDP signaling is deployed, a change in Route Distinguisher (RD) in the
root node is not acted upon for any PIM (S,G)s on the root node until the leaf nodes learn
about the new RD (via BGP) and send explicit delete and create with the new RD.
• Enhanced multicast load-balancing (config>system>load-balancing>mc-enh-load-
balancing) is mutually exclusive with PIM LAG usage optimization
(config>router>pim>lag-usage-optimization), since CPM-based load-balancing cannot
mimic data-path-based load-balancing in general cases (source IP unknown). Enabling
both options at the same time is not blocked, but may lead to multicast traffic disruptions
and thus, must be avoided. [179614]
• Packets arriving on the standby interface that belong to a standby stream for a given (S,G)
will be discarded and counted as either discards or mismatch against the (S,G) record. If the
standby interface and the RP interface are identical, then a discard counter is incremented.
If the standby interface differs from RP interface or RP interface is NULL, then a mismatch
counter is incremented. Auto-rebalancing when a new path becomes available is performed
for active joins.
• When multicast source geo-redundancy is enabled, MCAC may incorrectly account for
suppressed joins; therefore, Alcatel-Lucent recommends against enabling MCAC together
with the multicast source geo-redundancy feature. [185533]
IGMP Reporter • IGMP reporter has the following limitations:

− no support for MLD (IPv6 multicast)
− only supported on subscriber-interfaces
− no SAM support as collector device (collector device, in general, is not a part of
IGMP reporter)
− fixed MTU of 1400 bytes
PIM • In certain VPLS topologies where multiple multicast sources are connected to different PEs
configured with VPLS services using PIM-snooping, traffic duplication can occur on the
egress SAP/SDP. This is due to the PIM-snooping/proxy with (S,G)/(*,G) interaction not
working in accordance with draft-ietf-l2vpn-vpls-pim-snooping-06 (Appendix B.2).
[125379]
• In dual-homing PE scenarios where the path from the active source-PE to customer RP
fails and recovers, a customer’s channel (S,G) entry may remain programmed on the PE’s
VRF even if the receiver leaves the group. [152632]
• Alcatel-Lucent recommends using a minimum of 3.5 seconds hold time (Hello Interval
times Hello Multiplier) on PIM interfaces and to use BFD if faster link-failure detection is
required. [171934]
PPPoE • HTTP redirect is not supported for L2TP sessions at the LAC. Attempting to use HTTP
redirect IP-filters in ESM SLA-profiles that would be applied to L2TP sessions will block
the HTTP traffic on those sessions. [81316]
• Hierarchical Policing (H-POL) is not supported on L2TP LNS sessions.
• L2TP tunnel over GRE spoke-SDPs on an interface in a VRF is not supported.
• When using IPv6 subscriber management, all ports carrying traffic for subscriber hosts
must be on IOM3-XP/IMM cards or higher, including ports for non-subscriber-

Known Limitations
management interfaces within the same router and network interfaces. IPv6 traffic coming
in on IOM2-20g or IOM-20g-b destined for subscriber hosts may be dropped. [90606]
• When configuring reject-disabled-ncp below the PPP policy, the system will only reply to
a “PPP LCP Protocol Reject” message when an IPv6CP request is received while IPv6 is
not supported. An IPCP(v4) request while IPv4 is not supported will still be silently
discarded. [115620]
• With an incomplete SRRP setup for PPPoE subscriber hosts, IPv6 traffic originating on the
backup node of an SRRP pair may be sent towards the subscriber host if SRRP was not
active, causing that traffic to be dropped at the client. [117550]
• PPPoE, L2TP-LAC and L2TP-LNS are not supported on a 7450 ESS-6/6v in mixed mode.
[117721]
• Host-tracking Multi-Chassis Synchronization (MCS) is not supported on PPPoE hosts.
• To support L2TP, UDP port 49151 is used for internal communication. Care must be taken
this port is not blocked by any cpm-filter entry. [143110]
• For active PPPoE sessions in a dual-homed setup with DHCP leases granted via the
internal DHCPv4 client and DHCP server, care must be taken when shutting down SRRP
or taking it into an INIT state on both sides of the dual-homed setup. This will no longer
result in a timeout of the PPPoE sessions but the granted lease can still time out on the
DHCP server. The DHCP server then offering the same IP address to another DHCP client
can result in a conflict: “PPPoE session failure on SAP sap-id in service svc-id - … PPPoE
session with same IP * already exists in service svc-id”. To avoid these conflicts, either a
shutdown of the related group or subscriber interfaces or a manual clearing of the hanging
PPPoE sessions on both sides of the dual-homed setup must be executed. [203892]
• With new-qinq-untagged-sap disabled, the oldest PPPoE session can be terminated due to
an LCP echo timeout when both single- and double-tagged PPPoE sessions are active on a
SAP with QinQ encapsulation :X.0 (where X is any VID value different from zero (0)).
Enabling new-qinq-untagged-sap prevents double-tagged sessions to become active on a
SAP with QinQ encapsulation :X.0. A separate SAP must be created for double-tagged
PPPoE sessions in this case. [234099]
QoS • In a SAP ingress QoS policy with shared queuing, high-priority packets dropped will be
counted in the low-priority drops of the SAP ingress service queue statistics. [32335]
• When provisioning a network port on an MDA results in more than 8192 ingress queues
needing to be allocated on the MDA, the CPM and IOM can show different usage numbers
for ingress queues in certain situations. When this happens, the numbers will synchronize
back up when the newly-provisioned network port is deconfigured. [32878]
• When ler-use-dscp is enabled on network ingress and multicast VPRN traffic is tunneled
through an SDP, ingress classification on network ingress will happen based on the TOS
bits in the transport (outer) IP header as opposed to the customer IP packet. This behavior
is seen strictly in multicast VPRN packets. [40348]
• When the router is operationally down in a VPRN instance because the route-distinguisher
is not yet defined and PIM is then enabled on a VPRN SAP, the CPM will allocate
multicast queues for the SAP whereas the line card will not allocate queues because the line
card does not know that multicast is enabled on the interface. This disparity in allocation of
queues will exist only in the transitional phase until the route-distinguisher is set after
which the line card will allocate multicast queues and the line card and CPM will be in
synchronization. [42469]

Known Limitations
• Network control traffic (or other high-priority, expedited traffic) should not be configured
to share a queue on a port scheduler policy with non-expedited or lower priority traffic or
the queue could get into a state where the higher priority traffic will not be forwarded out
the egress port. This can also occur if the traffic is on two separate queues that are mapped
to the same level. [59298, 59435]
• Small amounts of packet loss may occur on queues configured with an MBS equal to or
lower than 4 KB and/or lower than two (2) times the maximum packet size of packets
forwarded by these queues. This can happen when the traffic rate through these queues is
large or when there is a large amount of jitter on this traffic. This packet loss is possible on
queues where the traffic rate is lower than the PIR. To avoid this type of packet loss, the
MBS of a queue should be configured to a minimum value of 5 KB or to two (2) times the
maximum expected packet size, whichever is higher. [66687]
• When sizing the mega pool based on the buffer-allocation requirements, the size is rounded
up to the nearest m5e4 and may result in no buffers being available for other pools. In non-
named-pool-mode, all port pools are guaranteed a minimum size of 16k (which is rounded
up to 6 buffers=18k). This guarantee does not apply to named-pool-mode and named
pools still have no minimum size (could be zero), but MDA default pools now have a
minimum size of 1 Mbyte. [80716]
• When the agg-rate-limit option is enabled on a Vport used by a subscriber, any subscriber
host queue that is parented to a virtual scheduler is not rate-limited by the Vport aggregate
rate. The queue will compete for bandwidth directly on the port's port scheduler, at the
priority level and weighted scheduler group at which the virtual scheduler is port-parented.
If the virtual scheduler is not port-parented, or if there is no port scheduler policy on the
port, the host queue will be orphaned and will compete for bandwidth directly based on its
own PIR and CIR parameters. [109318]
• WRR distribution across CVLANs will not be correct for certain combinations of class-
agg-weight and frame size, such that frame size/class-agg-weight results in a value lower
than 64 bytes. The system will round up the value resulting from frame size/class-agg-
weight to be at least 64 bytes. A few examples of such combinations are: 200-byte frames
and weight 8, 100-byte frames and weight 4, and 70-byte frames and weight 2. [112010]
• Network egress queue-groups cannot be used for frames coming from the CPM or CFM
other than IPv4, IPv6 and MPLS types. Other frame types (for example, ARP or IS-IS)
egress out of the per-port network-queue mapped to FC NC instead of the queue-group
queue. [115427]
• The advanced-config-policy sample-interval H-QoS parameter is supported only for
policers and not for queues. [125417]
• In-profile broadcast, unknown unicast and multicast traffic that is accounted as offered-
combined by a multi-point service queue is accounted as offered-uncolored in the
forwarding engine statistics on FP3-based line cards. [128123]
• Out-of-profile unicast traffic that is accounted as offered-colored by a unicast service queue
is accounted as offered-hi-priority in the forwarding engine statistics on FP3-based line
cards. [128133]
• When applying an ingress network-queue policy on an MDA that belongs to an IOM with
only one complex (that is, IOM3-XP) or that is inserted in a 7750 SR-c4/c12 chassis, the
network-queue policy will also be applied to the other MDAs belonging to the same IOM
or the same chassis. [138995]

Known Limitations
• When enqueue-on-pir zero is enabled on a queue, the PIR of the queue is not set to zero
immediately for inactive queues. Instead, the setting is applied only after the queue’s next
scheduling opportunity.
• The combination of Ethernet tunnels configured with access LAG emulation adapt-qos
distribute mode and an egress port scheduler is not supported. Since a port can be a
member of more than one eth-tunnel and those eth-tunnels could have different adapt-
qos modes, anything at the port level (like port-scheduler-policy, port queue-groups
queues, port queue-group schedulers and arbiter, agg-rates) will be unaffected by the eth-
tunnel adapt-qos mode.
• The port-fair mode on eth-tunnel will calculate the rates based on the number of active
paths and not based on the path bandwidth.
• When the CBS and MBS for a queue have similar or equal values, the system automatically
changes the CBS value to be larger than configured. This ensures that a request for a buffer
from the reserved pool is honored correctly when there are available buffers in the reserved
part of the queue’s pool. This does not change the operation of the MBS, which continues
to be the maximum drop tail for the queue. [149831]
• 802.3 SNAP frames are supported on SAP ingress QoS classification as part of MAC
criteria. IP QoS reclassification works only for Ethernet II or PPPoE frames at SAP egress;
it does not work with 802.3 SNAP frames. [188450]
• On egress, IPv4 QoS-based classification criteria are ignored when MAC-based ACLs are
configured.
• Concurrent MAC-based QoS/filter policy match criteria and IPv6-based QoS/filter policy
match criteria are not supported on access interfaces. On ingress, IPv6 routed packets
ignore MAC-based QoS classification criteria, while switched packets ignore IPv6-based
ACL match criteria. On egress, IPv6 QoS-based classification criteria are ignored when
MAC-based ACLs are configured. [208461]
• If an automatic data-path recovery action occurs on the 7750 SR-a4/a8, causing a control-
protocol failure, it is possible that no tmnxEqDataPathFailureProtImpact alarm is raised.
[209067]
• When a SAP egress QoS policy is applied to a B-VPLS SAP, any classification using ip-
criteria or ipv6-criteria statements is ignored for PBB-encapsulated traffic; the
classification does apply to non-PBB traffic egressing the B-VPLS SAP.
• When a SAP ingress QoS policy is applied to a B-VPLS SAP, any classification using ip-
criteria or ipv6-criteria statements will apply to PBB-encapsulated traffic except in the
case of IPv6 traffic when two inner VLAN tags are present.
• Remarking of the inner dot1p or DE bits based on the profile result of egress policing is not
supported.
Filter Policies • IP filters with a default-action of drop will not drop non-IP packets (such as ARP and
IS-IS). [40976]
• QoS and IP filter matches on IP frames are limited to Ethernet Type II IP frames. In
particular, Ethernet SNAP IP frames will not be matched with IP match criteria. [15692]
• MAC filtering does not match on IPv6-enabled IES interfaces. [44897]
• The HTTP-redirect action is allowed in MAC-filter policy configurations, but the action is
not supported for MAC-filter policies. [140058]

Known Limitations
• Configuration rollback may fail when rolling back changes on filters with entries
overwriting embedded-filter entries if the filter configuration at any stage of the rollback
exceeds the supported filter configuration limits. This can only happen when the embedded
filter entry and the embedding filter entry require different hardware resources. [162867]
• A CPM filter policy does not support an action-queue for VRRP protocol match but this
configuration is not blocked in CLI. [164497]
• For VPRN services that use GRE tunnels as transport, applying an egress ip-filter on the
network interface of the originating node will match fields of the inner IP header and not
the outer GRE IP header. [189799]
• The existing filter policy functionality does not provide notification when a PBR/PBF
redirect changes either as result of PBR target going down or being deleted, or as a result of
PBR target reprogrammed for a redirect policy. [198852]
• The PBR feature ESM downstream traffic steering using egress IPv4 ACLs with PBR
action has the following limitations.
− Only unicast traffic is subject to L3 PBR; any non-unicast traffic matching a Layer-3
entry will be subject to action forward. The same rule applies to traffic matching a
filter entry with an egress PBR action if the filter is deployed in the ingress direction.
− Local-to-local subscriber/host traffic when both subscribers are subject to VAS
scenario is not supported in production networks.
− The feature requires chassis mode D.
PBR/TCS • If a Transparent Cache Switching (TCS) redirect-policy destination does not have a test
clause defined, the operational state is reported as “Up”. [21227]
• An IP address must be assigned to the system interface and the interface must be
operationally up in order for Web portal or HTTP-redirect to operate. [46305]
• The Nuage Service Chaining for IES/VPRN using IPv4 filter ESI PBR for EVPN feature
has the following known limitations.
− Only unicast traffic is subject to PBR; other traffic matching a Layer-3 ESI PBR entry
will be subject to action forward.
− The egress EVPN interface must be in a VPRN service (same or different routing
instance).
− The Service Function appliance must be in the local IP subnet reachable via the
specified EVPN egress interface.
− The feature requires chassis mode D.
Services General • The CLI does not display an error when the user attempts to apply a filter log and a mirror-
source to a given SAP at the same time. A filter log and mirror-source cannot be applied
simultaneously to the same SAP. [22330]
• When the standby spoke-SDP of an endpoint becomes active due to a revert-time
expiration or a forced switchover, the Multi-Tenant-Unit (MTU) SAP may forward
duplicated packets (only of broadcast/multicast/unlearned unicast types) coming from the
redundant spoke-SDPs for a few milliseconds. For broadcast TV distribution and similar
applications where the duplicated packets may have a side-effect, Alcatel-Lucent
recommends that the redundant spoke-SDPs be operated in non-revertive mode. [67252]

Known Limitations
• If a configuration is saved (admin save) after enabling the MC-ring status by no shutdown
and the related configurations such as SRRP, BFD and IBCP are modified and cause a
“CONFIG_ERR” in MC-ring afterwards, the saved configuration may have reloading
issues. [78245]
• If an MC-ring breaks, slow RNCV is not performed and fast RNCV stops the moment one
of the peer detects the ring node. The ring node that detects the peer first receives the
connected status. [78246]
• When the ce-address-discovery option is enabled on an Ipipe VLL service and the
Ethernet SAP comes back up from an operationally down state due to link failure, the PE
node will forward IP multicast/broadcast packets over the Ethernet SAP but drops IP
unicast packets until an ARP message is received from the CE router. This is in accordance
to draft-ietf-l2vpn-arp-mediation. When the Ethernet VLAN SAP is switched through an
Ethernet switch or NTE device that does not implement Ethernet OAM fault propagation,
the CE node may not be aware of the link failure and will not generate an ARP message to
update the PE ARP cache until the time when the ARP cache in the CE times out. The only
workaround is to set the ARP cache timeout to a lower value on the Ethernet CE router.
[78805]
• A Multi-Site Scheduler (MSS) must either have a single (card-level) scheduler hierarchy
instantiated, or have a scheduler-hierarchy instantiated per member port for multi-member
logical ports such as LAG and APS, but not both. When an APS SAP is added to an MSS,
a site_instance is created for each APS group member port, and a scheduler hierarchy is
instantiated per site instance. If a regular (physical port) SAP was also to be added to the
same MSS, then a card-level scheduler hierarchy would be created. The per site-instance
scheduler hierarchies and the card-level scheduler hierarchy within the MSS are
disconnected and therefore would not provide a meaningful H-QoS function. [81279]
• A GRE SDP is not supported over an RSVP shortcut. The GRE SDP will go down if the
destination is reachable via an RSVP shortcut route. [91257]
• LDP-over-RSVP transport is not supported for BGP SDPs (RFC 3107). SDPs configured
in this manner will become operationally up but no traffic will be forwarded. [91592]
• For Distributed CPU Protection, the rate limiting is per-protocol per-SAP (or per network
interface). It does not support rate limiting per individual subscribers within a single SAP.
This limitation also applies to capture SAPs. All control traffic for subscribers that have not
yet established an MSAP is treated as a single aggregate (per protocol). Configuration is
via CLI and SNMP; there is no RADIUS support.
• Configuration of IPv6 is not supported on Ipipe spoke-SDP terminations in an IES or
VPRN service context. [128543]
• The following features are not supported on EVPN-enabled Routed-VPLS interfaces in
VPRN services: IS-IS, RIP, OSPF, and authentication-policy. [168271]
• An R-VPLS interface binding to a VPLS service will make the R-VPLS interface
operationally down if the R-VPLS interface MAC-address matches a static-MAC or OAM-
MAC configured in the associated VPLS service. In this scenario, to restore the R-VPLS
interface to be operationally up, either one of the following actions need to be taken:
− Change the R-VPLS interface MAC-address
− Remove the conflicted static- or OAM-MAC address and then unbind and re-bind the
R-VPLS interface configuration. [170516]

Known Limitations
• For R-VPLS, configuring service-mtu to a value lower than 142 will result in packets
exceeding the configured service-mtu value being dropped with no IP fragmentation.
[180872]
• Support of XMPP on a DC PE in VPLS/VPRN requires the user to use all lowercase letters
while configuring the username field with config>system>xmpp server xmpp-
servername>create username user-name password password domain-name domain-
name. The CLI/SNMP does not reject configuring any uppercase letters, but only
lowercase letters are functionally supported. This is due to ejabberd (Erlang Jabber
Daemon) interoperability issues and how ejabberd interprets uppercase user names.
[190076]
• EVPN IP routes will not be added to the RTM if the VPRN service is operationally down,
except if it is down because of a missing route-distinguisher configuration. [192237]
• VCCV BFD is not supported on MPLS-TP PWs (that is, where pw-path-id is configured).
• BFD sessions, where the BFD Template specifies type cpm-np, are not supported by
VCCV BFD.
• The following limitations apply for Pseudo-Wire SAPs (PW-SAPs):
− PW-SAPs require IOM3-XP and are supported with the HS-MDAv2
− PW-SAPs are only supported on Epipe VLL services, as well as on interfaces and
group-interfaces in an IES or VPRN service.
− Only Ethernet PWs are supported
− Ethernet CFM is not supported on the Ethernet PW or PW-SAP
− No support for mixed SDP types
− No support for PW control word
− No support for hash-labels
• The XMPP support on DC PE for the VPLS/VPRN (Fully-Dynamic model) feature is not
supported in combination with the RADIUS-triggered dynamic data services feature in the
same system. The two features are mutually exclusive.
• For XMPP support on a DC PE for the VPLS/VPRN Fully-Dynamic model, when the VSD
creates a configuration in the system, rollbacks could fail in those situations where policies
are created by CLI/SNMP but the association to services is provisioned by the VSD.
• Protocol classification and identification of underlying functions are not supported at either
ingress or egress for frames received at ingress with more than two VLAN tags.
• The configuration of Epipe services is not supported from VSD through the Fully-Dynamic
integration model, although Epipe commands are shown in the tools dump service vsd-
services command-list. [217287]
• Assuming force-vlan-vc-forwarding is configured in a PW-template being used by BGP-
AD, when provider-tunnel is enabled and its owner is bgp-ad, the root node does not
preserve the ingress tag. [218480]
EVPN on VPLS • BGP-EVPN MPLS is only supported in regular vpls and b-vpls services. Other VPLS
and B-VPLS types, such as etree, i-vpls or m-vpls, are not supported.
services • IGMP-snooping is not supported in VPLS (or I-VPLS) services when bgp-evpn mpls is
enabled (in the service or the associated B-VPLS). Although the command is not blocked,
IGMP reports and queries are not sent to EVPN destinations when igmp-snooping is

Known Limitations
enabled (the static-group or send-queries commands would be needed on SAPs/SDP-

bindings). The same behavior described before is valid for MLD-snooping.
• CPE-ping is not supported on EVPN services but is supported in PBB-EVPN services
(including I-VPLS and PBB-Epipe). CPE-ping packets are not sent to EVPN destinations.
CPE-ping only works on local active SAP/SDP-bindings in I-VPLS and PBB-Epipe
services.
• The proxy-arp/nd functions are fully supported in EVPN-MPLS services, including on
SAPs/SDP-bindings that are part of an ethernet-segment. However proxy-arp/nd are not
supported on I-VPLS.
• When debug router bgp update is enabled and EVPN-MPLS routes are received, the
label-1 value shown in the debug output will not match the value shown in the show
router bgp routes evpn. The debug output shows the entire 24-bit values as received on
the route and show commands display the value interpreted as Label or VNI based on the
received RFC 5512 tunnel-encapsulation extended community.
• In general, no SR OS-generated control packets are sent out to EVPN destinations. The
only exceptions are CFM traffic (from UP MEPs, MIPs, and vMEPs) and proxy-ARP/ND
messages (confirm messages).
− eth-cfm (MEPs, vMEPs, MIPs) can be configured and used in EVPN-
VXLAN/MPLS VPLS services (at the service level, and on the SAPs and SDP-
bindings).
• xSTP and M-VPLS services:
− xSTP can be configured in bgp-evpn services. BPDUs are not sent over the EVPN
bindings.
− bgp-evpn is blocked in m-vpls services, however, a different m-vpls service can
manage a SAP/spoke-SDP in a BGP-EVPN-enabled service.
• In bgp-evpn-enabled VPLS services, mac-move can be used in SAPs/SDP-bindings;
however, the MACs being learned through BGP-EVPN will not be considered.
• disable-learning only works for data-plane-learned MAC addresses.
• The following features/commands are not supported in combination with bgp-evpn mpls:
− mac-protect
− provider-tunnel
− bgp-vpls
− endpoint and attributes
− Subscriber management commands under service, SAP and SDP-binding interfaces
− mld/pim-snooping and attributes
− vsd-domain
− vxlan must be shutdown under bgp-evpn
− bpdu-translation
− l2pt-termination
− mac-pinning
− spb configuration and attributes
− allow-ip-int-bind (R-VPLS) and bgp-evpn ip-route-advertisement
− bgp-evpn unknown-mac-route

Known Limitations
• ESI PBF is not supported across VPLS services (i.e., the interface on which the steering
takes place and EVPN VPLS interface must be in the same VPLS service).
• BUM traffic matching an IPv4/MAC ESI PBF filter for EVPN will be unicast forwarded to
the VTEP:VNI resolved through PBF forwarding.
EVPN multi- • EVPN multi-homing (MH) and BGP-MH cannot be enabled in the same VPLS service.
homing BGP-MH can still be used for multi-homing as long as no ethernet-segments are
configured in the service SAPs/SDP-bindings. Note that, although only one BGP-MH site
can be configured in EVPN-VXLAN services, there is no specific limitation in terms of the
number of BGP-MH sites supported on an EVPN-MPLS service.
• SAPs/SDP-bindings belonging to a given ethernet-segment but configured on non-BGP-
EVPN-MPLS-enabled VPLS or Epipe services will be kept operationally down with a the
StandByForMHProtocol flag.
PBB-EVPN • When bgp-evpn mpls is enabled in a B-VPLS service, an I-VPLS service linked to that
B-VPLS cannot be an R-VPLS (the allow-ip-int-bind command is not supported).
• The ISID value of 0 is not allowed for PBB-EVPN services (I-VPLS and Epipes).
• The following features/commands are not supported in an I-VPLS when bgp-evpn mpls is
configured in the B-VPLS service:
− mac-protect and auto-learn-mac-protect
− end-point and attributes
− eth-tunnels
− sharing of ports or SDPs between a B-VPLS service enabled with bgp-evpn mpls and
its associated I-VPLS/Epipe services is not allowed.
PBB-EVPN • PBB-EVPN multi-homing and BGP-MH cannot be enabled in the same I-VPLS service.
multi-homing • ethernet-segments can be associated with B-VPLS SAPs/SDP-bindings and I-
VPLS/Epipe SAPs/SDP-bindings; however, the same ethernet-segments cannot be
associated with B-VPLS and I-VPLS/Epipe SAP/SDP-bindings at the same time.
• When PBB-Epipes are used with PBB-EVPN multi-homing, the following restrictions
apply:
− PBB-Epipe spoke-SDPs are not supported on ethernet-segments.
− For non-local-switching PBB-Epipes (there is a single SAP per Epipe) only all-active
multi-homing is supported.
− For local-switching-enabled PBB-Epipes (two SAPs are defined within the PBB-
Epipe instance):
− only single-active multi-homing is supported
− only when the two ends of the PBB-Epipe are defined in two systems (and not
three or more)
QinQ Default SAPs • The following constraints must be considered when configuring *.null and *.* QinQ SAPs:
− only supported in Ethernet ports or LAG

Known Limitations
− only supported on Epipe, PBB-Epipe, VPLS and I-VPLS services. They are not
supported on VPRN, IES, R-VPLS or B-VPLS services.
− capture SAPs with encapsulation :*.* cannot co-exist with a default :*.* SAP on the
same port
− inverse-capture SAPs (*.x) are mutually-exclusive with :*.null SAPs
− no support for:
− PW-SAPs
− eth-tunnel or eth-ring SAPs
− VLAN-translation copy-outer
− E-tree root-leaf-tag SAPs
− Subscriber-management features
− BPDU-translation
− IGMP-snooping
− MLD-snooping
− ETH-CFM primary-VLAN
Subscriber • Dynamic subscribers learned (via DHCP) while sub-sla-mgmt is shut down will continue
Management to use the SAP-level ingress and egress filter rules. Once the subscriber is relearned
(renewed), the subscriber profile filters will then be used. This does not apply to static
subscribers. [47167]
• Since the SR routing model is based on a broadcast Ethernet network, the IP addresses of
the subnet (for example, x.y.0.0/16 or x.y.z.0/24) and the subnet broadcast address (for
example, x.y.255.255/16 or x.y.z.255/24) should not be used as IP addresses for both IPoE
(DHCP/static/ARP) subscribers. PPPoE hosts can use these addresses starting from
Release 9.0.R3 with the support for PPPoE unnumbered interfaces. [78233]
• When a CoA request is sent for changing the subscriber-ID of a subscriber host in a dual-
stack PPPoE session, both the IPv4 and IPv6 hosts will have their information changed.
This may temporarily increase the subscriber count on the SAP, which should be reflected
in the multi-sub-sap limit. [90556]
• In a network where DHCP Relay is dual-homed, a VPLS SAP with DHCP-snooping
enabled will receive two identical DHCP reply messages from the DHCP server. When
RADIUS authentication is enabled on the VPLS SAP and the DHCP server did not echo
the Option 82 information, RADIUS authentication will be executed again for DHCP reply
messages. For dhcpACK messages, if the SR OS still has an outstanding RADIUS
transaction from the first dhcpACK when receiving the second dhcpACK, the latter one
will be dropped and a dhcpRelease message will be incorrectly generated towards the
DHCP server. When RADIUS authentication is successful for the first dhcpACK, the client
will still receive the dhcpACK and starts using the IP address. [101767]
• Direct replication over subscriber hosts in the subscriber management context has been
extended to support replication to two new modes, but have the following limitations:
− Per SAP replication — in this mode, only a single copy of a multicast stream per SAP
is transmitted regardless of the subscriber management deployment model (subscriber
per SAP, service per SAP or a single SAP per all subscribers). For example, if
multiple hosts on a SAP are subscribed to the same multicast group, only a single

Known Limitations
copy of multicast stream will be sent towards the access network. In this model,
multicast traffic is flowing outside of the subscriber queues. IGMP states are
maintained per host and SAP.
− Multicast traffic can be redirected to a different interface from the interface on which
IGMP join has arrived. Redirection is supported within a VRF, within the GRT and
between VRFs. However, redirection between the GRT and a VRF (and vice versa) is
not supported. Multicast redirection is a new feature and should not be confused with
host tracking although the functionality of the two are very similar. Host tracking is
still supported. For a given subscriber, the usage of IGMP and host tracking is
exclusive; they cannot both be active on the same subscriber.
• When a subscriber host makes use of policers feeding into queues, the queuing statistics
require the reconciliation of the policer and queue statistics. Therefore, Alcatel-Lucent
recommends waiting at least 10 seconds after traffic has stopped before issuing a clear
statistics command. [115390]
• The following ESM Multi-Chassis Sync (MCS) client applications are not blocked in CLI
but should not be enabled in MCS on hybrid ports in production networks: igmp, igmp-
snooping and mld-snooping. [123469]
• When using host-lockout on managed SAP's using one VLAN for all PPP sessions, some
sessions can become locked-out during the initial setup in case of high setup rates [126348]
• The following restrictions for DHCPv4 over PPPoE apply:
− The DHCPv4 client must be connected via a CPE that acts as a DHCP Relay.
− The DHCPv4 client subnet must be known as a managed route attached to the
subscriber PPPoE host (next-hop of managed route is the PPPoE host)
− The DHCP Relay Agent IP address (giaddr field) inserted by the CPE DHCP Relay
must be part of the managed route subnet (not the subscriber PPPoE host’s IP address)
− Downstream DHCPv4 over PPPoE frames will be sent through the egress SLA
instance queues of the PPPoE subscriber; hence, they are part of the subscriber QoS
scheduling context. [137283, 138115, 138890]
− The DHCP server is not local on the node where the PPPoE/LNS session is
terminated. [138242, 138972]
• An SR OS-based DHCPv6 server can only be used in combination with an SR OS-based
DHCPv6 relay on a group interface with Enhanced Subscriber Management (ESM)
enabled or with an SR OS-based DHCPv6 relay on a regular service interface. Using an
SR OS-based DHCPv6 server as a standalone server with a non-SR OS-based DHCPv6
relay is not supported. [149028]
• The following restrictions apply for the Wholesale/Retail routed-CO model:
− An up-front Layer-3 DHCPv4 or DHCPv6 relay agent in combination with
Wholesale/Retail configuration is not supported. [72138]
− Leaking of a subscriber prefix from a retailer VPRN into a different local VPRN or
leaking static, managed or BGP routes that have a subscriber prefix as next-hop is not
supported. [134840, 140643]
− No support for static IPv4 hosts on unnumbered retail subscriber interfaces [150733]

Known Limitations
− Synchronization of subscriber IGMP/MLD states between redundant BNG nodes

protected via the same MC-LAG/SRRP protection mechanism and part of a
Wholesale/Retail setup is currently not supported. The IGMP/MLD state will be
synchronized to the standby node but will fail installation with the reason
“IGMP/MLD interface not found”. [155540]
− ESM multicast enables ESM group-interfaces to process each host’s IGMP and/or
MLD messages; and hence, enabling IPv4 or IPv6 multicast delivery to individual
ESM host. ESM multicast is supported only if both the Wholesale and Retail are
VPRN services. ESM multicast is not supported if the Retail is an IES instance.
[179941]
− Overlapping addresses in retail services (private-retail-subnets) are supported for
PPPoEv4, PPPoEv6 and IPoEv6. They are not supported for IPoEv4. [191027]
− No multi-chassis redundancy support in combination with overlapping addresses in
retail services (private-retail-subnets)
− IES as a retail service is not supported for IPoEv4 hosts
− No support for PPPoA and PPPoEoA sessions
− Unique IPv4 subnet per subscriber for IPoE (virtual-subnet) is not supported in a
retail service.
− Web Portal Protocol (WPP) is not supported on a retail subscriber interface
• L2TP tunnels over LDP shortcuts are not supported. [154574]
• The initial DHCP message of an internal DHCPv4 client for PPPoE requests a lease-time
of one hour. However, the next DHCP renew or rebind will use the last granted lease-time
from the DHCP server. If the granted lease-time was equal to the Maximum Client Lead
Time (MCLT) because of a local-dhcp-server used in failover mode, Alcatel-Lucent
recommends enforcing at least the default lease-time of one hour by configuring the pool
min-lease-time. [157485]
• Although “FRAMED INTERFACE ID” is configured below the RADIUS Accounting
policy, the parameter can be missing in the Accounting-Stop message for certain
termination root causes such as “User Request(1)” and “Admin Reset(6)”. This is not an
issue for termination root cause “Lost Carrier(2)”. [164568]
• Setting up a Diameter peer TCP connection via VPRN is only supported with the default
TCP port 3868. [186325]
• Persistency file sizes larger than 2GB are not supported. When a persistency file reaches
the 2GB file size limit, an event is raised and persistency will stop saving data to the
compact flash. An operator intervention is required to re-initialize the persistency file using
the following CLI commands: config system persistence client-application no location
followed by config system persistence client-application location cflash-id. [199023]
• IPoE IPv6 hosts that share a /64 prefix (ipoe-bridged-mode) with separate sla-profile
instances are not supported. Egress traffic for these hosts will share a single (arbitrary) set
of sla-profile instance queues/policers. [199934]
• A configuration rollback can fail when a static IPv6 host is configured on group-interface
SAPs [200715]
• The oversubscribed multi-chassis redundancy model in ESM has the following limitations:
− Central standby node must use SF/CPM4 or higher (other protected nodes can
continue to use SF/CPM3).

Known Limitations
− All nodes in the OMCR cluster (central standby and the protected nodes) must run
Release 12.0.R1 or higher.
− While the node is in the central standby mode of operation, the configuration of 1:1
(active-active) peering session on the same node is blocked. In other words, the
central standby mode of operation becomes the only mode of operation on that node.
However, non-central standby nodes can have a peering connection with a central
standby backup node (OMCR mode of operation) and at the same time another
peering connection with another active BNG node in the 1:1 model.
− Only DHCPv4/v6 subscribers in the Routed Central Office (RCO) model are
supported.
− Synchronization of the following MCS clients is not supported:
− Host tracking
− MC-ring
− Layer-2 subscriber hosts
− Layer-3 IGMP/MLD
− Layer-2 IGMP/MLD
− DHCP Server
− PPPoE Clients
− MC-LAG
− MC-IPsec
− MC-endpoint
− The failover trigger is based on SRRP only (no MC-LAG support).
− Pre-emption of already instantiated subscriber hosts in the central standby node by
another subscriber hosts is not allowed.
− Persistency in multi-chassis environment must be disabled since redundant nodes are
protecting each other and they maintain up-to-date lease states.
• An IPv6 subscriber can be mirrored/LI’d using the subscriber ID as the mirror/LI source
criteria, but a specific IPv6 host cannot be a source criteria (only the subscriber which will
include all IPv6 hosts associated with that subscriber ID).
• The maximum number of hosts within the subscriber or the SLA-profile instance that can
be affected by a single CoA is 32.
• IPoE hosts with separate SLA-profile instances and duplicate MAC addresses on a single
SAP with nh-mac antispoofing are not supported. Ingress traffic for these hosts will share a
single (first created) set of SLA-profile instance queues. This restriction has been in place
since Release 6.0.
• BGP peering between CPE and BNG via a managed route is not supported.
• An SR OS-based DHCPv6 relay on a regular interface cannot be used in combination with
antispoof ip/ip-mac/mac on the SAP.
• An SR OS-based DHCPv6 relay on a regular service interface cannot be used in
combination with an authentication policy on that interface.
• Diameter NASREQ authentication is not supported
− for L2TP LAC hosts nor L2TP LNS hosts
− on group-interfaces of type lns or wlangw

Known Limitations
• The following restrictions apply for IPoE sessions:

− IPoE sessions cannot be enabled on a group-interface of type wlangw.
− ARP hosts are not supported in an IPoE session and cannot be instantiated on a group-
interface with IPoE sessions enabled.
− A local user database host identification based on option 60 is ignored when
authenticating an IPoE session.
− RADIUS authentication of an IPoE session fails when the user-name-format is
configured to dhcp-client-vendor-options, mac-giaddr or ppp-user-name
− The alc.dtc.setESM() API in the DHCP Transaction Cache (DTC) Python module
cannot be used in combination with IPoE sessions.
− The DHCP Python module (alc.dhcp) used to derive subscriber host attributes from a
DHCPv4 ACK message is not supported in combination with IPoE sessions.
− Subscriber services cannot be enabled on an IPoE session.
− An IPoE session cannot be used as a control channel for dynamic data services.
− WPP is not supported in combination with IPoE session
− The creation of an IPv4 host using the Alc-Create-Host attribute in a RADIUS CoA
message is not supported on a group-interface with IPoE session enabled.
− A RADIUS CoA message containing an Alc-Force-Nak or Alc-Force-Renew
attribute is not supported for IPoE sessions.
• The following restrictions apply for Layer-3/IP accounting introduced in Release 12.0.R1:
− Layer-3/IP accounting is not supported in combination with last-mile-aware shaping
on HS-MDAv2 MDAs
− Layer-3/IP accounting is not supported in combination with ESMoPW on HS-
MDAv2 MDAs
− Layer-3/IP accounting is not supported in combination with MLPPP
− Layer-3/IP accounting in combination with ESMoPW and last-mile-aware shaping
may be inaccurate if the MPLS encapsulation overhead changes during the lifetime of
a subscriber.
− Layer-3/IP accounting is restricted to a single encapsulation per SLA-profile instance
(queue instance). The first host associated with the SLA-profile instance (queue
instance) determines the allowed encapsulation. Conflicting encapsulations are:
− PPPoE and IPoE on regular Ethernet SAPs
− PPPoE and IPoE on PW-SAPs
− PPPoA and PPPoEoA on ATM ports
− PPPoE keepalive packets do not contain IP payload and introduce an error in Layer-
3/IP accounting when enabled in combination with L2TP LAC. A workaround is to
isolate the keepalives in a separate queue/policer.
− Padding of frames smaller than the Ethernet minimum frame size (64 bytes) may
introduce an inaccuracy in Layer-3/IP accounting.
− With ATM in the last mile, last-mile-aware shaping may introduce an inaccuracy in
Layer-3/IP accounting.
− Packet-Byte-Offset (PBO) changes during the lifetime of a subscriber introduces an
inaccuracy in Layer-3/IP accounting.

Known Limitations
• On HS-MDAv2, there is no per-egress queue granularity to count IPv4- and IPv6-

forwarded/dropped subscriber traffic separately. When stat-mode v4-v6 is configured on an
egress HS-MDAv2 queue, it is applied to all egress queue-group queues for that subscriber.
• uRPF on group interfaces cannot be used in combination with VPRN type subscriber-
split-horizon.
• mac-sid-ip anti-spoofing for PPPoE on the group-interface cannot be used in combination
with L2TP LAC.
• ESM is supported on the 4-port 100GE CXP, 4-port 100GE CFP4, and 40-port 10GE SFP+
IMMs with the following restrictions:
− static SAPs (non MSAP) are only supported with policers on ingress
− MSAPs are for laboratory use only and require service-queuing and profiled-traffic-
only configured.
• Diameter multi-chassis redundancy is not supported for OMCR (Oversubscribed Multi-
Chassis Redundancy). Diameter applications (Gx, Gy, NASREQ) in general are not
supported in combination with OMCR. Gx for Usage-Monitoring and AA is currently not
supported in multi-chassis configurations.
• Stateful MC-LAC redundancy does not protect tunnels against a node failure for failover
recovery-method mcs, introduced in Release 13.0.R1. Stateful MC-LAC redundancy does
protect tunnels against a node failure for failover recovery-method recovery-tunnel.
• L2TP data shunt is not supported.
• In case the same L2TP tunnel client endpoint is shared by LAC sessions under multiple
group-interfaces, then all SRRP instances need to share fate using an oper-group: all
SRRP instances in the group will switch together to the redundant LAC when an error is
detected.
• When LAC sessions under a group-interface are spread over multiple LAC tunnels with
different L2TP tunnel client endpoints, all interfaces used for LAC tunnel client endpoint
addresses need to track the same SRRP instance for fate sharing.
• ESM host lockout is not supported for LNS.
• When using Python-policy cache persistency on the 7750 SR-a4/a8, a persistency-
downgrade to Release 12.0.R9 or 13.0.R1 is not supported. [201175]
• When multiple identical framed routes are received for a single subscriber host or
IPoE/PPP session, only the first framed route will be accepted while all subsequent
identical framed routes are silently ignored. Framed routes are considered identical when
prefix and prefix length are the same, irrespective of the specified metrics. This applies to
both IPv4 and IPv6 framed routes. [205607]
• For 7750 SR-7/12/12e, 7450 ESS-7/12 and 7450 ESS-7/12 mixed mode chassis types, the
unnumbered DHCPv6 IA-NA subscriber hosts are limited to 128k per system, or to 64k per
system in case the unnumbered DHCPv6 subscriber hosts are terminated on a retail
subscriber interface (Wholesale/Retail). This limit is not enforced by the system.
Unnumbered DHCPv6 IA-NA subscriber hosts are those that have a prefix that falls
outside the provisioned subscriber WAN-host prefixes on the subscriber interface. Support
for unnumbered subscriber hosts must be explicitly enabled per subscriber interface with
the allow-unmatching-prefixes CLI command for IPv6. [206968]
• When DHCPv6 IA-PD is modeled as a managed route pointing to an IPv4 subscriber host
as next-hop (pd-managed-route next-hop ipv4), the following restrictions apply.
− There are no ingress or egress IPv6 filters installed for traffic from/to the PD prefix.

Known Limitations
− There are no ingress or egress QoS IPv6 criteria installed for traffic from/to the PD
prefix.
− Multicast replication to the PD prefix is not supported.
− Diameter Gx is not supported on static hosts and L2TP LAC/LNS hosts.
− Diameter Credit Control (Gy) is not supported on L2TP LAC hosts.
− The following restrictions apply for PCC rules initiated from Diameter Gx.
− PCC-rules are not supported on L2-Aware NAT hosts.
− PCC-rules are not supported on L2TP LAC sessions. L2TP LAC sessions should
not be part of an SLA-profile instance where other subscriber hosts/sessions with
PCC rules are active. [209165]
Multi-Chassis • MCS synchronization of MLD-snooping is not supported. The related command is not
Synchronization blocked for backward-compatibility reasons, but has no effect on the system if configured.
PW-SAP for Epipe • Capture SAPs are not supported

VLL Services • Ethernet CFM is not supported on PW ports or PW-SAPs.
• PW Ports only support dot1q or QinQ encapsulation.
• The Independent Mode of PW Redundancy is not supported. That is, the PW Port only acts
as a slave from the perspective of PW preferential forwarding status.
VLL Spoke • If the control word is modified on a TPE device in a pseudowire switched environment
Switching with either a Cisco or an Alcatel-Lucent router running a previous software revision as the
SPE device, it may be necessary to toggle the spoke binding status on the SPE device (l2vfi
connection in the case of a Cisco). [57494]
VPLS • Remote MAC Aging does not work correctly due to ECMP, LAG or multiple paths that
span different IOMs/IMMs/XCMs. If you have ECMP, LAG or multiple LSPs and a
remote MAC learned on a given IOM/IMM/XCM moves to another IOM/IMM/XCM, the
MAC will be first aged out of the FDB table when the remote age timer expires, even if the
MAC is not idle. It will be then relearned on the new IOM/IMM/XCM. [33575]
• In a distributed VPLS configured with SDPs transported by MPLS (LDP/RSVP) where the
ingress network interface for a given SDP is moving due to network events from one
IOM/IMM/XCM to another IOM/IMM/XCM, the MAC addresses remotely learned on
that SDP will start to age-out regardless of whether they are still active or not until twice
their configured remote-age value is reached. Their ages will be then set back to 0 or the
address will be removed from the FDB as appropriate. [47720]
• In a distributed VPLS configuration, it may take up to (2*(Max Age)-1) seconds to age a
remote MAC address, and in cases of CPM or CFM switchover, it may take up to (3*(Max
Age)-1) seconds. [48290]
• A user VPLS SAP might stop forwarding traffic after the SAP port bounces if that SAP is
managed by a management VPLS (mVPLS) with Spanning Tree Protocol disabled. The
workaround is to remove the mVPLS if the Spanning Tree Protocol is not required. If
Spanning Tree Protocol is required, it should be enabled on the mVPLS. [60262]

Known Limitations
• When a CPM or CFM switchover occurs during STP convergence, a temporary traffic loop
or a few seconds of traffic loss may occur. [77948, 78202]
• The RSTP and MSTP Spanning Tree Protocols operate within the context of a VPLS or
mVPLS service instance. The software allows for the configuration of an STP instance per
VPLS service instance. The number of STP instances per VPLS or mVPLS service
instance depends on 1) the number of SAPs/SDPs per VPLS and 2) the number of MAC
addresses active within a VPLS.
• When using Ethernet Ring Automatic Protection Switching (R-APS) as defined in G.8032,
CCMs and G.8032 R-APS messages continue to be forwarded in the control VPLS even if
the service or its SAPs are administratively shut down. The Ethernet ring instance can be
shut down to stop the operation of the ring on a given node.
Routed VPLS • If PIM is configured on the IP interface of a routed I-VPLS service, any IPv4 multicast
traffic sent over that interface will be flooded into the I-VPLS but not into the B-VPLS.
[212347]
Proxy-ARP/ND • Proxy-ARP/ND are not supported on the following services or in combination with the
following features:
− B-VPLS
− I-VPLS
− M-VPLS
− R-VPLS
− ETREE
− Subscriber-management, ARP-reply-agent, host connectivity (SHCV), residential
split-horizon-groups, DHCP/DHCPv6, ARP-MSAP trigger, ARP-host configured.
− VPLS Interface (although configurable, proxy-ARP/ND is not supported) [220190]
− Alcatel-Lucent recommends using send-refresh only with CPM3-XP or higher CPM.
IES • In the saved configuration for IES services, the IES instance and interfaces will appear
twice: once for creation purposes and once with all of the configuration details. This allows
configuration items such as DHCP server configuration to reference another IES interface
without errors. [56086]
• If two IES interfaces are connected back-to-back through a 2-way spoke-SDP connection
with SDPs that have keepalive enabled and IGP is enabled on the IES interface with a
lower metric as the network interfaces, the related SDPs will bounce due to SDP keepalive
failure. The GRE-encapsulated SDP-ping reply will be ignored when it is received on an
IES interface. [68963]
VPRN/2547 • VPRN service traffic with the DF (Do Not Fragment) flag set and requiring fragmentation
to be transported through an SDP tunnel is correctly discarded, but an ICMP Type 3 Code 4
(fragmentation needed and DF set) message is not issued. [18869]
• The service operational state of a VPRN might be displayed incorrectly as Up during its
configuration while some mandatory parameters to bring it up have yet to be set. [31055]

Known Limitations
• Dynamic Multipath changes might not work in the case of VPN-IPv4 routes and might
require a restart of the service. [31280]
• Each MP-BGP route has only one copy in the MP-BGP RIB, even if that route is used by
multiple VRFs. Each MP-BGP route has system-wide BGP attributes and these attributes
(preference) can not be set to different values in different VRFs by means of vrf-import
policies. [34205]
• The triggered-policy feature does not apply to vrf-import and vrf-export policies in a
VPRN. One needs to reset the target VRF instance in order to re-evaluate these policies or
to disable the triggered-policy feature. [43006]
• Executing a ping from a VPRN without a configured loopback address may fail with a “no
route to destination” error message despite there being a valid route in the routing table.
The error message is misleading and should state that the reason for the failure is not
having a source address configured. [55343]
• Misconfiguring the network so that two VPRNs leak the same prefix from VPRN to GRT
results in only one leaked route in the GRT. After correcting the misconfiguration, an
additional shutdown and no shutdown of the VPRN is required. [92147]
• VPRNs auto-bound to GRE tunnels cannot co-exist with IGP shortcuts since the line cards
or CFM cannot forward GRE-encapsulated traffic for tunneled next-hops. [91863]
• Only regular IPv4 and IPv6 route-type routes leaked from the VPRN into the Global
Routing Table (GRT) are supported. Unsupported route types are: aggregate, BGP-VPN
extranet, managed, subscriber, 6-over-4 IPv6, or 6PE IPv6 routes.
• If a VPRN is configured with auto-bind-tunnel using GRE and the BGP next-hop of a
VPN route matches a static blackhole route, all traffic matching that VPN route will be
blackholed even if the static blackhole route is later removed. Similarly, if a static
blackhole route is added after auto-bind-tunnel GRE has been enabled, the blackholing of
traffic will not be performed optimally. In general, static blackhole routes that match VPN
route next-hops should be configured first, before the auto-bind-tunnel GRE command is
applied. [167012]
• All locally-originated route-target routes are withdrawn when any VPRN is shut down. The
new route-target routes corresponding to the remaining active VPRNs are re-originated
after a short delay. This churn can be mitigated by not using BGP rapid-withdrawal and by
making sure that the min-route-advertisement time is longer than two (2) seconds under
normal conditions. [179437]
• In case of multiple VPRNs on the same node when two (2) VPRN routes with same RDs
are compared, the VPN next-hop metric is used, which can be derived from either of the
VPRNs. This causes inconsistent behavior when ECMP is enabled in one of the VPRNs.
Toggling the operational state of one of the VPRNs can change the order of which route is
selected. [197655]
• An SDP is always preferred over auto-bind tunnel irrespective of the Tunnel-Table
Manager (TTM) preference. [199763]
VRRP/SRRP • The MAC address displayed for an SRRP gateway IP in the show router arp output on a
subscriber interface does not show the MAC address of the Virtual Router but is that of the
interface. Use the show srrp command to see the VR MAC address actually in use.
[57838]

Known Limitations
• If the in-use priority on each side of an SRRP connection goes to zero, both routers will
incorrectly elect themselves as master. [60032]
• Under a VRRP policy, host-unreachable events can be configured. If the address
configured is not reachable on the active CPM/CFM, the policy will use the configured
priority to affect VRRP instances. Upon a High-Availability switchover, the address will be
deemed reachable for a while. This period depends on the Interval and Drop Count
configured under the event. Once the period is over, the policy event will properly reflect
whether the address is reachable or not. [161154]
VXLAN • VXLAN R-VPLS services can only be bound to VPRN interfaces and not IES interfaces.
[173106]
• When a BGP-EVPN route advertised from a Data Center (DC) controller has a VTEP
endpoint (next-hop in the BGP-MH NLRI) in the same local subnet as the DC-PE’s egress
network interface, the IP next-hop will not be resolved. It is required to have a Layer-3
router between the DC-PE’s egress network interface and the remote VTEP, or a /32 static
route to the remote VTEP. [182672]
EVPN for VXLAN • A given <VTEP, Egress VNI> pair is restricted to one given VPLS service; hence, a MAC
route with the same <VTEP, Egress VNI> cannot be imported into two different services
even if they have the same import-RT. The MAC will only be installed in one service. A
trap will be raised to warn the user when there has been an attempt to add the same <VTEP,
Egress VNI> to more than one service.
• The system IP-address is used in EVPN-VXLAN as the source VTEP of all the VXLAN
packets and as the BGP next-hop in all the BGP-EVPN advertisements. When changing the
system address, an administrative toggling (shutdown/no shutdown) is required in the
BGP-EVPN context of the VPLS services so that the new system address is used as the
BGP next-hop. Note that the system address cannot be changed as long as BGP-EVPN is
administratively enabled (protected by CLI). The source VTEP of the VXLAN packets is
changed immediately though, without any additional action [167775].
• In general, no SR OS-generated control packets will be sent to the VXLAN auto-bindings,
except for ARP, VRRP, ping and BFD. Although vMEPs can be configured and used for
tests on the WAN side, ETH-CFM tests will not work through VXLAN. This behavior is
expected since no ETH-CFM is supported in the Data Center (DC) and ETH-CFM flooding
to the DC Network Virtualization Edge (NVE) devices is absolutely undesired.
• Although xSTP can be configured in BGP-EVPN services, BPDUs will not be sent over
the VXLAN bindings. BGP-EVPN is blocked in mVPLS services, however a different
mVPLS service can manage a SAP/spoke-SDP in a BGP-EVPN-enabled service.
• mac-protect and provider-tunnel is not supported in EVPN-enabled VPLS services.
• mac-move, disable-learning and other FDB-related tools only work for data plane learned
MAC addresses and therefore, not for control plane learned MAC addresses in EVPN-
enabled services.
• VPRN interfaces bound to EVPN-enabled R-VPLS services do not support the following
parameters: arp-populate, authentication-policy.
• BFD is not supported on EVPN-tunnel interfaces.
• EVPN-VXLAN BGP routes are not imported if the BGP next-hops are resolved over a
non-network interface, for instance, an IES interface.

Known Limitations
IPsec • In a multi-active tunnel group setup, ICMP pings to the tunnel’s local address may fail.
[140341]
• BFD over IPv6 over IPsec is not supported.
• IPsec DHCP Relay uses only the gi-address configuration found under the IPsec gateway
and does not take into account gi-address and src-ip-addr configuration below other
interfaces. [224586]
TMS • There is no octet counter support for the three internal ISA-TMS ports (off-ramp, on-ramp
and internet). [115132]
• For TMS ECMP routes, the route age is the age of the last added route or age of the first
remaining route. [115525]
• TMS routes are not reconciled dynamically on the standby CPM and will therefore flap
during a High-Availability switchover. [115532]
• TMS ECMP routes are only counted once under show router route table summary.
[120740]
• The offramp- and mgmt-VPRN interface must be on IOM3-XP or higher. [126826]
PBB • For access multi-homing over MPLS for PBB Epipes, the following features are not
supported: PW switching, BGP-MH, network-domains, mac-ping, mac-populate, mac-
purge, mac-trace, or support for RFC 3107, GRE and L2TPv3 tunneling.
Video • A sequence of configuration changes, multicast traffic start and set top box activity may
lead to a mix up between the (*,G) and (S,G) records on the MS-ISA. Alcatel-Lucent
recommends configuring PIM SSM to avoid the issue.
This may result in a slow FCC or unrepaired packet loss. The show video channel com-
mand has two entries in that case: one for (*,G) and one for (S,G). The FCC/RET counters
should step up on the (S,G) entry, not the (*,G). If the (*,G) FCC/RET counters increments,
the workaround is to use the clear router pim database command to get out of the state.
[82353]
• In normal operating conditions, the RTP-sequence numbers for a channel are increasing
monotonically. An equipment failure upstream of the video-interface (such as rewrapper-
issue, intentional reset of sequence numbers) may lead to a situation where this assumption
no longer holds. The MS-ISA may, depending on the channel characteristics, take up to ten
(10) minutes to resume proper operation if such an event should occur. [110872]
FCC RET • Up to four (4) ISA groups with one (1) MS-ISA are supported, or one (1) Video group with
four (4) MS-ISAs .
Ad Insert (ADI) • The frequency of IDR frames in the network and ad streams must be less than one IDR
frame every 1.3 seconds.
Mirroring/Lawful • Simultaneous Filter Logging and Service Mirroring on egress is not supported. When
Intercept simultaneously performing filter logging and service mirroring at egress, the service
mirroring operation takes precedence over the filter logging operation. This behavior was

Known Limitations
introduced in Release 2.0. In Release 1.3 and earlier releases, the filter logging takes
precedence and the service mirroring of the packet is not performed.
• If a dot1q SAP is being mirrored on an IES interface, DHCP responses from the server to
the DHCP clients are not mirrored. A workaround is to mirror the port instead of the SAP.
[40339]
• A redundant remote mirror service destination is not supported for IP Mirrors (for example,
a set of remote IP mirror destinations). The remote destination of an IP Mirror is a VPRN
instance, and an endpoint cannot be configured in a VPRN service.
• Multi-chassis APS (MC-APS) groups cannot be used as the SAP for a redundant remote
mirror destination service. APS cannot be used to connect the remote mirror destination
7750 SR nodes to a destination switch.
• OAM vccv-ping is not supported on mirror service spoke-SDPs (or ICBs in the case of PW
Redundancy being used for redundant mirror services). This is primarily because mirror
traffic is uni-directional.
• LI/Mirroring at the LAC for subscribers using MLPPPoX access is not supported. Alcatel-
Lucent instead recommends LI at the LNS.
• LI at the LNS for MLPPPoX (oE/oA/oEoA) subscribers is only supported with a mirror-
dest type of ip-only. No other mirror-dest types are supported for MLPPP subscribers at
the LNS.
• If q-tagged traffic is mirrored to a mirror-destination SAP and the SAP has an egress QoS
policy containing IP-based reclassification, the IP-based reclassification is ignored.
[132504]
• NAT-based lawful interception criteria (that is, configure li li-source x nat ... in CLI) can
not be configured/triggered/used via RADIUS.
• Mirroring services and Lawful Intercept (LI) are not supported with a segment-routing
tunnel when the tunnel is used in a BGP shortcut and in resolving a BGP unicast label
route.
L2TPv3 SDP • The implementation of L2TPv3 for SDP transport does not support:
− Any L2TPv3 control plane functionality
− Support sequence numbering
− Fragmentation and reassembly
− Session ID configuration or validation
− Authentication – the only authentication of tunnel payload is performed through
validation of Source Address, Destination Address, and the ingress cookie
− Service multiplexing – each SDP will transport one spoke-SDP
Unless explicitly mentioned above, most pseudowire/Epipe features are not supported on
L2TPv3 SDPs or spoke-SDP bindings, including but not limited to:
− Layer-3 functionality
− Pseudowire shaping
− Ingress/egress QoS functionality
− Pseudowire switching
− Active/standby pseudowire services and inter-chassis backup
− PBB

Known Limitations
− Hash-label
− PW Status signaling
Operators expecting to deploy this feature set should contact their Alcatel-Lucent engineer-
ing support teams.
NAT • Executing a traceroute from an inside NAT interface may result in an unexpected source
IP address in the response packet when the max session limit is exceeded. [91154]
• There are some limitations to the functionality of the Application Layer Gateways (ALGs)
in combination with NAT64 due to the way the ALG translations are done.
When translating inside-information into outside information, IPv6 addresses are translated
into IPv4 addresses without any issues, but when an IPv4 addresses is received in the pay-
load of an incoming message, this address will not be translated because it is a random
ouside address and not a NAT address. In the NAT44 case, this is not an issue because the
inside host can connect to this address, but in the NAT64 case, the inside host cannot con-
nect to an IPv4 host.
This has an impact on the possible scenarios involving the ALGs:
− SIP — The connection information in a SIP message describes the IP addresses and
ports to be used to connect to the other party of the call. From the perspective of a
client behind a NAT64 gateway, his own IP address will be translated correctly, but
the IP address received from the other side may be an IPv4 address and will not be
translated into an IPv6 address. Thus, the NAT64-client will not be able to initiate a
connection to the other client. If only one client is behind a NAT64 gateway, SIP-calls
are still possible. When client A (IPv4) can connect to client B (NAT64), client B can
use this connection to connect back to client A. If both clients are behind the NAT64
gateway (the same or different), both clients will receive each other’s IPv4 outside
addresses and no client will be able to start the connection.
− RTSP — Connection information in an RTSP message describes the IP address and
ports to be used by the client to receive the actual video/audio/etc. traffic. If the client
is behind the NAT64 gateway, the server will receive correctly translated connection
information and the client will be able to receive the data sent out by the server. If the
server is behind the NAT64 gateway, the server will not receive translated connection
information and the server will not be able to send out the data to the client.
− FTP — Some servers may abort the connection when they receive the wrong type of
address according to their current connection.
• The config aaa isa-radius-plcy radius-acct-server source-address-range command
depends on the number of maximum MS-ISAs configured in all NAT-groups, including the
MS-ISAs that were removed before the node rebooted. For every MS-ISA, a unique source
address is used.
• L2-Aware NAT is typically used with DHCP-proxy where the IP-address assignment to the
ESM subscriber-host is handled via RADIUS. In this application, the same IP address can
be assigned to multiple subscriber-hosts. This allows for IP address sharing between
subscriber-hosts, which is the main purpose of L2-Aware NAT.
In cases where L2-Aware NAT is used with DHCP-relay (instead of proxy) where the IP
address is assigned directly by the DHCP server, the IP lease can be extended only by

Known Limitations
DHCP rebind messages that are broadcasted. Any attempt to renew the IP lease by unicast
DHCP renew message will fail.
This issue should not be a problem since the DHCP protocol will switch to multicast DHCP
rebind after a few failed attempts to renew the IP lease via a unicast DHCP renew message.
• Policy-Based Routing (PBR) is not supported in conjunction with L2-Aware NAT. In cases
where PBR is enabled for L2-Aware NAT, traffic will be NAT’d but PBR will not be
executed.
• Static 1:1 NAT is not supported for L2-Aware NAT, DS-Lite or NAT64.
• L2-Aware NAT is not supported on the Retail service in a Wholesale/Retail Routed-CO
model. Large-scale NAT can be used instead.
• All ingress traffic subject to NAT has to ingress on an IOM3-XP or higher if deterministic
NAT is configured on the service and if multiple ISA cards are present in the nat-group. If
this condition is not met, tmnxNatMdaDetectsLoadSharingErr error events will be
generated and traffic ingressing older IOMs, subject to NAT, will be dropped. [150597]
• NAT Policy Application Layer Gateways (ALGs) are not supported in combination with
filtering address-and-port-dependent. [229124]
Application • When deleting an application or an application group, statistics for the current accounting
Assurance interval will be lost. The workaround is to first remove all references to the application and
application group thereby allowing the accounting intervals to occur, and then delete the
application or application group.
• For an active flow, when an application assignment is changed in an app-filter, or an app-
group assignment is changed in an application, the flow count for the associated protocol is
doubled.
• All subscribers being serviced by an ISA card must be removed from the ISA prior to
removing the card from an “application-assurance-group”. [77394]
• Application Assurance does not support traffic divert to/from R-VPLS services; this
includes traffic divert for SAP or spoke-SDP interfaces in both R-VPLS and linked
IES/VPRN services. Similarly, Application Assurance does not support traffic divert
to/from a PBB service.
• Only ESM subscribers (both static and dynamic via DHCP/RADIUS) are supported in a
Wholesale/Retail VPRN configuration.
• In a Wholesale/Retail configuration, AA is supported on the ESM subscribers or on the
aggregate traffic SAP facing the retailer’s network, but not on both.
• When creating new AA group partitions, unique partition ID values should be used across
all groups.
• When creating AA policers, unique policer names should be used across all groups.
• If hosts for a single ESM subscriber are present in multiple service instances, simultaneous
traffic in the separate service instances with the identical IP 5-tuple may be mis-classified
by AA. [91809]
• If Cflowd export from AA exceeds the rate that the CPM/CFM can process, Cflowd
packets may be silently discarded. [91811]
• At a 1 Gb/s rate, a single TCP session or UDP flow must have an average packet size
greater than 250 bytes. If the average packet size is less than 250 bytes, fairness between
sessions/flows cannot be guaranteed. [98658]

Known Limitations
• Spoke SDP divert is only supported on services to/from FP2- and higher-based line cards.
• The divert line card must be FP2- or higher-based when using IPv6.
• AA Redundancy Protocol (AARP) does not support multicast traffic.
• AARP is not supported on the 7750 SR-c4.
• During the small period of time it takes to create a new Seen-IP subscriber, packets to or
from that subscriber may be recorded as policy-bypass errors. These policy-bypass error
packets are correctly forwarded but are neither classified nor recorded against the
subscriber. [139622]
• AARP is not supported between 7750 SR-c12 and non-7750 SR-c12 chassis types.
• PCRF has to reinstall, using a RAR, any AA-usage monitoring AVPs after an IPoE session
migration process of AA ESM Gx controlled subscribers is completed.
Cflowd • On a 7450 ESS-6/6v, AA Cflowd options can be configured, but no Cflowd data will be
transmitted. Cflowd is not supported on 7450 ESS-6/6v. [101281]
• Cflowd is not supported on subscriber SLAs.
• Persistency of the Cflowd Global if-index is not supported. [148012]
• With the higher rate of performance of Cflowd on the 7950 XRS and newer 7750/7450
CPM3s or CPM4s, it is possible to generate more collector bound packets than the CPM
management Ethernet port can handle. In these cases where Cflowd is expected to handle a
very high number of flows, it is suggested that all collectors are reachable via in-band
routes.
• Cflowd sampling traffic ingressing or egressing a non-Ethernet SAP has limited support.
For non-Ethernet SAPs, the encapsulation will only be reported as zero (0). [162360]
• While Cflowd can be configured under SAPs on a 7450 ESS platform, Cflowd processing
is not supported on these platforms, except on 7450 ESS-7 or 7450 ESS-12 platforms with
mixed mode enabled. [162472]
sFlow • In Release 13.0.R6, scale limits for sFlow will be enforced to avoid IOM resource
exhaustion. If sFlow is enabled on a port with more than 50 SAPs or on an IOM with more
than 1600 SAPs, sFlow will be administratively disabled. The number of SAPs must be
reduced to an allowed limit prior to re-enabling sFlow on the associated port or IOM.
Alcatel-Lucent recommends reducing the number of SAPs below these limits before
upgrading to Release 13.0.R6 release or later. [216190]
• sFlow is not supported for PW-SAPs. [217715]
BFD • When an SRRP instance uses its own BFD, L3 MC-ring cannot be enabled. BFD may be
enabled in subscriber SRRP or MC-ring, but not both. [73063]
• When using multi-hop BFD for BGP peering or BFD over other links with the ability to
reroute such, as spoke-SDPs, the interval and multiplier values should be set to allow
sufficient time for the underlying network to re-converge before the associated BFD
session expires. A general rule of thumb should be that the expiration time (interval *
multiplier) is three times the convergence time for the IGP network between the two
endpoints of the BFD session.
• Multi-hop BFD currently does not support LDP shortcut routes. [135994]

Known Limitations
• BFD VCCV on a BGP VPWS or BGP VPLS service may not interoperate with third-party
implementations that require a response to a VCCV-ping echo request message in order to
maintain the corresponding BFD session. [184152]
• The support for multi-hop BFD port 4784 was introduced in SR OS Releases 9.0.R12 and
all later major releases. This is only supported if the chassis mode is D. In chassis mode C
and lower, multi-hop BFD will only work with UDP port 3784. [185612]
OAM • Timestamping the SAA versions of Loopback and Linktrace are only applied by the sender
node. The total time of delay for Loopback and Linktrace tests includes the packet
processing time of the receiver node, which may be very inaccurate depending on the CPU
load of the receiver node at the processing time. Accurate results can be gathered through
the use of Y.1731 two-way-delay, which includes native time stamping and the removal of
remote processing times. [87326]
• If a mac-ping or mac-trace request is sent with an unknown source MAC address and
there are multiple SAPs, the user will see duplicated results because the request is flooded
to each SAP and each SAP sends a reply to the request message. This is the expected
behavior. [16298]
• The oam vprn-ping and oam vprn-traceroute commands for VPRN in a hub-and-spoke
topology using hairpin routing do not work. If a hub-and-spoke topology is used, the spoke
site must be associated with the hub VRF or the default route created must point to the hub
site not a blackhole. If not, some sites will not be reachable from the spoke site.
• The oam vprn-ping and oam vprn-traceroute commands do not work in a hub-and-spoke
network topology with the 7750 SR or 7450 ESS in mixed mode, or 7950 XRS as the
Customer Edge (CE) hub. As a workaround, the 7750 SR or 7450 ESS in mixed mode, or
7950 XRS will send a control plane response from the hub to the requester Provider Edge
(PE) to confirm connectivity to the hub PE.
• OAM DNS lookups are not working correctly if the full DNS name is not provided.
[54239, 54689]
• An OAM Service Ping request for a VPRN service is always sent over the data plane (over
the spoke SDP) and not through the control plane. A VPRN Ping should be used to send a
ping request using the control plane for a VPRN instance. [58479]
• ATM OAM F4 cells on a VPC Apipe service are always sent with a PTI equal to four (4)
for SEG cells and a PTI equal to five (5) for end-to-end cells. [75052]
• Even if source-mac is specified when using oam cpe-ping, the resulting ARP request
packet sent to the CPE device will still use the chassis base MAC address. [85034]
• E-LMI is not supported on LAG interfaces.
• LDP-treetrace may not discover all ECMP paths and may report discovery status as
“unExplrdPath”. This occurs when multiple back-to-back parallel ECMP interfaces exist in
the network. Each of the multiple link hops cause the IP address range of 127/8 used by
LDP treetrace LSR hash route to be split equally into the number of parallel paths. It is
possible that when that space decreases too much that there will be ECMP paths that will
not be reported by the ldp-treetrace tool. [112806]
• ldp-treetrace, ping and traceroute may not work properly during an LDP-FRR event until
IGP has converged, if originated on the node experiencing the failure and traveling over the
link being protected. [115907, 121716]

Known Limitations
• ETH-CFM extraction is not supported on SDPs and bindings created via BGP-AD. By
extension, vMEPs are not support in VPLS contexts using BGP-AD.
• An lsp-trace of an LDP FEC can return a “DSMappingMismatched” error in the presence
of ECMP paths. This is because the ingress LER selects the first ECMP next-hop provided
by the responding LSR for populating the Downstream Mapping (DSMAP) TLV in the lsp-
trace packet for the next TTL value. If the LSR hashing the packet for the next TTL value
chooses a different downstream path to forward the packet, the error is returned by that
downstream node.
• In order to properly trace the single path of a FEC, the user must add the path-destination
option and enter a specific 127/8 address to be used in the IP destination address field of the
echo request packet and in the DSMAP TLV such that the control plane and the data plane
at the hashing LSR will use the same downstream interface. In addition, the user can
discover all ECMP paths via the use of the ldp-treetrace command and trace all paths of
the FEC. [150970]
• The following OAM tool commands are not supported with BGP-AD VPLS spoke-SDP
and PMSI, and with BGP-VPLS spoke-SDP: mac-ping, mac-trace, mac-populate with
flood option, mac-purge with flood option, and cpe-ping. [152529]
• The ETH-CFM primary-VLAN function will not extract ETH-CFM PDUs on QinQ
Ethernet SAPs that specify an outer tag (x) and a value of zero (0) for inner tag (<port-id
|lag-id>:x.0) on the 7950 XRS platform. This is also the case for all other SR OS routers
that enable the new-qinq-untagged-sap option. [153841]
• sdp-ping and sdp-mtu are not supported with an P2MP spoke-SDP used as an I-PMSI in
VPLS context.
• p2mp-lsp-ping is not supported with an RSVP P2MP LSP or an mLDP FEC used as an I-
PMSI in VPLS context [154657].
• p2mp-lsp-trace is not supported with an RSVP P2MP LSP used as an I-PMSI in VPLS
context. [154659]
• Operators who opt to change the default values for dot1q-etype or qinq-etype will not be
able to use primary-VLAN functionality. [154756]
• When lsp-trace is originated on a BGP IPv4 labeled route that is resolved to an LDP FEC
which itself is resolved to an RSVP LSP, OAM packets are forwarded by the ingress LER
using two labels (T-LDP and BGP). The LSP-trace will fail on the downstream node with
return code <rc=11 No label entry at stack-depth <RSC>> since there is no label entry for
the T-LDP label. [159125]
• PBB-Epipes configured with spoke-SDPs must not have the fault-propagation option
configured under any MEP attached to a spoke-SDP. This is an unsupported configuration
for PBB-Epipes using spoke-SDPs. [163737]
• When OAM is to be originated/terminated in a SAP context on a given LAG with per-fp-
sap-instance enabled, Alcatel-Lucent recommends using, at minimum, a one-second (1 s)
interval timer. When scaling SAPs on LAG, even larger timer values may be required,
especially on older hardware. Failure to do so may result in OAM sessions going down
during LAG-member port status changes. [175261]
• The following OAM tools are not supported with segment-routing (SR) IS-IS or OSPF
tunnels:
− LSP-level OAM: lsp-ping and lsp-trace
− PW-level OAM tools: vccv-ping and vccv-trace are not supported for PW-switching

Known Limitations
− Service-level OAM: svc-ping, cpe-ping, vprn-ping, vprn-trace, mac-ping, mac-

trace, mac-purge, and mac-populate
E-Tree • When configuring root-leaf-tag SAPs, the root-tag VID or the leaf-tag VID cannot be
zero (0). Therefore the following SAPs are NOT supported as root-leaf-tag SAPs:
− SAPs on null-encapsulated ports (root-leaf-tag SAPs must be on dot1q- or QinQ-
encapsulated ports)
− sap :0 root-leaf-tag leaf-tag X
− sap :X root-leaf-tag leaf-tag 0
− sap :* root-leaf-tag leaf-tag X
− sap :X.Y root-leaf-tag leaf-tag 0
− sap :0.* root-leaf-tag leaf-tag X
Where X and Y are any VID value different from zero (0) or *. The following SAPs are
however supported as root-leaf-tag SAPs:
− sap :X.* root-leaf-tag leaf-tag Y
− sap :X root-leaf-tag leaf-tag Y
− sap :X.Y root-leaf-tag leaf-tag Z
Where X, Y and Z are any VID value different from zero (0) or *.
• pw-path-id is not allowed for SDP-bindings configured in VPLS E-Tree services. This is
valid for root-ac, leaf-ac and root-leaf-tag SDP-bindings. Static PWs are fully supported,
however.
• No SONET/SDH with BCP encapsulation is supported in VPLS E-Tree services.
• The following features are not supported in VPLS E-Tree services:
− BGP, BGP-EVPN, BGP-AD, and BGP-BVPLS
− GSMP
− VXLAN
− legacy OAM commands (cpe-ping, mac-ping, mac-trace, mac-populate and mac-
purge)
• The following features are not supported in VPLS E-Tree SAPs:
− capture SAPs
− eth-tunnel SAPs
− eth-ring – E-Tree SAPs can be used as eth-ring data SAPs but control G.8032 traffic
is not supported in VPLS E-Tree services.
• The following features are not supported in VPLS E-Tree SDP bindings:
− vlan-vc-tag under an sdp-bind when it is configured as root-leaf-tag.
DNSSEC • Full DNSSEC validating resolver is not supported.

• DNSSEC AD-bit validation is not executed during the boot phase.
• DNSSEC AD-bit validation is not supported for the WLAN-Gateway GTP interworking
function.

Known Limitations
OpenFlow • ofp_match oxm IPv6-label encoding is aligned to four (4) bytes, not three (3) bytes,
although only 20 bits are relevant.
• of1DecodeOxmTlvInt [ERR]: icmpv4_type field cannot be masked; it is rejected even if
the mask is all one (1).
• The OXM value should be the same after applying the mask. If not, it is rejected. [166673]
• A CPM/CFM switchover causes the TCP connection with the OpenFlow controller to
bounce. Flow states are preserved. [167252]
• OpenFlow controller is not informed when, due to an operational event or configuration
change impacting OF programmed rule, the programmed flow table action for Layer-3
PBR actions or Layer-2 PBF action is changed to or from drop or forward. The exception to
this issue is steering to RSVP-TE or MPLS TP LSP.
• Hybrid OpenFlow Switch (H-OFS) is enabled by deploying an IPv4/IPv6 ACL that:
− embeds an OpenFlow switch instance
− or chains to a system filter that embeds an OpenFlow switch instance
The OpenFlow-enabling IPv4/IPv6 ACL filter is supported in the following contexts:
− config>router>if>ingress>filter
− config>service>ies>if>sap>ingress>filter
− config>service>ies>if>spoke-sdp>ingress>filter
− config>service>vprn>if>sap>ingress>filter
− config>service>vprn>if>spoke-sdp>ingress>filter
− config>service>vprn>network>ingress>filter
− config>service>vpls>sap>ingress>filter
− config>service>vpls>mesh-sdp>ingress>filter
− config>service>vpls>spoke-sdp>ingress>filter
Deploying an OpenFlow-enabling ACL in other contexts is not blocked and should not be
done in production networks. [199550]
NETCONF/YANG • The following NETCONF protocol operations are not supported: <lock>, <unlock>.
• The NETCONF port is not configurable. NETCONF sessions are supported on TCP port
830 (as required in RFC 6242). NETCONF sessions received on other TCP ports
(including 22) are not supported.
• The <get> operation is supported with a CLI content layer format only (no XML format for
operational state data).
• The <candidate> datastore is not supported.
• Leading or trailing spaces in string values (for example, descriptions or names provisioned
via CLI) are not preserved in a <get-config> XML-formatted response.
• The alu-conf-log-r13.yang module does not correctly model the keys of the event-control
list. The event-number is not included as a key due to limitations of the underlying
infrastructure in handling parameters that are optional keys in CLI (the “no” form of event-
control does not require the event-number). NETCONF edit-config requests and get-config
responses can correctly use the <event-number> tag as a key (to write and read event-
control configuration) but the YANG module does not model it.

Known Limitations
• Due to tight coupling between CLI and NETCONF infrastructure, non-standard XML
output occurs in a <get-config> response in several scenarios. The following are some
scenarios where this occurs.
− A <get-config> response may return containers that are empty (such as
<dns></dns>). These empty containers occur in the same places where CLI info or
admin save configuration files also have empty CLI branches (such as dns
immediately followed on the next line of output by exit). Section of 7.5.8 of
RFC 6020 states that YANG does allow these empty containers; however, some tools
may generate warning messages.
− Containers and objects are repeated in a <get-config> response in some cases. SR OS
NETCONF <edit-config> requests and <get-config> responses for the <running/>
datastore contain ordered content layer objects. Dependencies between objects
sometimes require part of a container or object to be configured first; the rest of the
container or object can be configured later (perhaps after other parts of the
configuration model have been specified).
− The <shutdown> leaf is repeated within a container or object in some cases. For
example, this is done in filters (such as inside <management-access-filter><ip-filter>)
so that the filter is first operationally disabled (<shutdown>true</shutdown>), then
updated, and then finally operationally enabled (<shutdown>false</shutdown>).
− Leaf-list parent nodes are repeated for each leaf-list entry in some cases (for example,
the <member> leaf-list under <configure><system><security><user>).
ISSU • ISSU can use the Soft Reset mechanism and if used, is subject to any limitations of Soft
Reset in the source/starting release of the upgrade. See Soft Reset in the Known
Limitations section for the source/starting release.
• Limitations specific to ISSU across minor releases (“Minor ISSU”) are as follows:
− Minor ISSU is supported on platforms with redundant CPMs (but not on 7750 SR-
a4/a8) or CFMs. Minor ISSU support is not available on the 7750 SR-c4.
− Minor ISSU is supported across up to a maximum of 20 minor releases (the starting
release of the ISSU must always be the R4 minor release or later).
• Limitations specific to ISSU across major releases (“Major ISSU”) are as follows:
− Major ISSU is supported on platforms with redundant CPMs, except for 7750 SR-
a4/a8. Major ISSU support is not available on the 7750 SR-c4/c12, as these platforms
utilize CFMs instead of CPMs.
− Major ISSU is supported across a single major release (i.e., Release 10.0 to Release
11.0)
− Major ISSU is supported for all paths 12.0.Rx → 13.0.Ry where:
− x and y are ≥ 4 (x ≥ 6 for 7950 XRS-40)
− The release date of 13.0.Ry is at least 90 days later than the release date of
12.0.Rx.
− A Major ISSU (M-ISSU) switchover, when a multi-chassis APS port is active and the
VRRP port feeding that APS port is master as well, may result in a longer outage on
impacted channels. This issue is more likely to happen in a high-scale setup (i.e., high
numbers of APS groups) with SF/CPM2 cards.

Known Limitations
As a workaround, either the APS ports or the VRRP master should be moved to the
other MC-APS router before the M-ISSU upgrade. [157196]
• In MC-IPsec scenarios, a multi-chassis switchover to the standby chassis must be
performed before performing ISSU; otherwise, an extended data loss may occur if the
MCS link goes operationally down.
• ISSU is not supported on the 7750 SR-a4/a8 or 7750 SR-1e/2e/3e platforms.
• New firmware is provided on certain IMMs and MDAs in certain releases in order to
enable or enhance the IEEE 1588 port-based timestamping feature:
− Release 13.0.R3
− p10-10g-sfp (in imm-2pac-fp3) [202916]
− p6-10g-sfp (in imm-2pac-fp3) [202916]
− Release 13.0.R4
− m12-1gb+2-10gb-xp
− m12-1gb-sfp
− Release 13.0.R8
− p20-ge-sfp (in imm-2pac-fp3)
Note: In order to enable the firmware, the operator must hard reset (clear) the IMMs or
MDAs (clear mda) after an ISSU, if ISSU is used to upgrade SR OS. This firmware is not
automatically upgraded during a Soft Reset because it is not a mandatory firmware
upgrade.
• If ISSU is used to upgrade to Release 13.0.R4 or later, the system will not automatically
change to the faster switch-fabric speed (the tools command and reboot will be necessary
after the ISSU for the faster speed to go into effect).
Soft Reset • Although the data plane interruption during a Soft Reset is minimized, there is a brief (non-
zero) traffic interruption. Transit protocol packets can be affected by this interruption.
• In scaled configurations, the following protocols may experience interruptions in peering
sessions during a Soft Reset on the 400 G line cards (for example, 4-port 100 GE) when
using the default protocol timers:
− Broadcast IS-IS (point-to-point IS-IS is not impacted)
− RSVP
− P2MP LSPs
− LDP (T-LDP is not impacted).
Increasing the protocol timers in the configuration will prevent interruptions in the protocol
peering sessions. BFD (which is not impacted by the Soft Reset traffic interruption) could
be used in conjunction with larger protocol timers in order to have fast failure detection.
• If the far-end node of an Ethernet OAM (802.3ah) session is not an SR OS router with the
support for the vendor-specific Grace TLV, then the Ethernet OAM sessions are interrupted
briefly during a Soft Reset and will take down the associated port and protocols running on
that port. Ethernet OAM grace is disabled at the system level by default and must be
enabled prior to an ISSU in order to take advantage of this functionality
(config>system>ethernet>efm-oam).
• LLDP information is lost when a card is Soft Reset, but relearned once the Soft Reset is
completed.

Known Limitations
• LACP sessions (Link Aggregation Control Protocol – IEEE 802.3ax standard, formerly
802.3ad) using the default “fast” timers may briefly go down during a Soft Reset
(dependent on card types and configuration). The LACP sessions will recover within a few
seconds. LACP sessions using “slow” timers will not go down during a Soft Reset.
• If the far-end node of an Ethernet CFM (802.1ag CC) or Y.1731 session is not an SR OS
router with the support for the proprietary SR OS ETH-CFM grace period, then the
Ethernet CFM or Y.1731 sessions are interrupted briefly during a Soft Reset. Without the
grace-period support, configured intervals of less than one (1) second will result in the
sessions going down. Intervals of one (1) second may cause the sessions to go down in
some cases (dependent on other configuration). Sessions with intervals of 10 seconds or
higher will not go down even without the grace-period support.
• Soft Reset outage times may be higher than expected if one or more line cards are Soft
Reset while the standby CPM is rebooting. [73285]
• The architecture of some IMM cards prevents the support for the hard-reset-unsupported-
mdas functionality for a manual clear/reset during a Minor ISSU. In most software upgrade
cases, these cards can simply be Soft Reset (without the need for the hard-reset-
unsupported-mdas), but if there is a mandatory firmware update on these cards, then they
must be hard reset. The hard-reset-unsupported-mdas option is blocked for the following
IMM types: imm1-40gb-tun, imm5-10gb-xfp, imm1-100gb-cfp, imm12-10gb-sf+, imm3-
40gb-qsfp, imm-1pac-fp3 and imm-2pac-fp3. [158482]
• Soft Reset is not supported on the 7750 SR-a4/a8 or 7750 SR-1e/2e/3e platforms.
FlowSpec • For flow routes, there is no support for next-hop resolution, interaction of router policies
and flow route NLRI fields, or configurable prefix-limit.
• Installed validated flowroutes do not disappear when next-hop disappears.
• Packets with options hit the filter entry, but are still forwarded to the CPM/CFM and routed
via routing table information.
Accounting • The extended-service-ingress-egress record accounting is designed only for lower-scale

deployments that require extra information and is not available in other types of records.
• When extended-service-ingress-egress record is selected for an accounting policy, the
minimum collection-interval must be 15 minutes. The total number of SAPs that use the
new accounting record type must not exceed 2048. [142879]
WLAN-GW • To support migrant users’ host promotion and logging, UDP port 1011 is used for internal
communication. This port should not be blocked by any cpm-filter entry.
• The distributed RADIUS proxy is only guaranteed to handle access-request packets of up
to 640 bytes. [221041]
• RADIUS Access-Accept packets up to a maximum of 512 bytes are guaranteed to be
handled. [225073]

Resolved Issues
Resolved Issues
The following sections describe specific technical issues that have been resolved in SR OS
releases. See also Known Limitations, as some known issues may have been moved to that
section.
Notes:
• Issues marked as MI might have had a minor impact but did not disturb network traffic.
• Issues marked as MA might have had a major impact on the network and might have disturbed
traffic.
• Issues marked as CR were critical and might have had a significant amount of impact on the
network.
Release 13.0.R10
HW/Platform • The mechanism for the standby CPM/CFM to switch over from the active CPM/CFM in
case of a hardware issue has been improved to avoid false positives and dual CPM/CFM
resets. [219603-MI]
• In certain rare scenarios where an MS-ISA2(-E) experienced a software issue, it was
possible for the ISA to remain in a “not equipped” state. To recover the MS-ISA2(-E), a
clear card or power-cycling was required. This issue has been resolved. [230625-MA]
• Automatic recovery actions for a rare, transient error on an FP3-based forwarding plane
might have resulted in a few seconds of traffic impact across the affected forwarding plane.
The recovery period is now been reduced to less than a second. [230669-MI]
CLI • Prior to Release 13.0.R10, CLI compact flash usage warnings and alarms commands
(configure system thresholds cflash-cap-warn | cflash-cap-alarm) with negative values
for rising-threshold and falling-threshold resulted in out-of-limit values. This issue has
been resolved. [68449-MI]
System • Prior to Release 13.0.R10, if names or descriptions included the following special
characters, and these names ended up in XML accounting files, the special characters were
not properly expanded according to the XML standard.
− < (less-than)
− & (ampersand)
As a result, applications may have been unable to parse the resulting XML file. The work-
around was to not use special characters in names and descriptions related to accounting.
This issue has been resolved. [228893-MI]
OpenFlow • OFPT_FLOW_MOD messages were sometimes not processed when received immediately
after controller connection was re-established after a CPM/CFM High-Availability

Resolved Issues
switchover. The controller could have delayed sending OFPT_FLOW_MOD messages by

three (3) seconds to avoid this problem. This issue has been resolved. [226292-MA]
LAG • In rare cases on a 7950 XRS, depending on the order in which XMAs came up on an XCM,
traffic being forwarded out of a LAG member port of a multi-port LAG might have been
dropped. When a LAG member port was in this state, bouncing it restored traffic
forwarding. This issue has been resolved. [231799-MA]
Routing • Committing changes to a policy that calls a sub-policy or changing an object used in the
sub-policy will no longer cause system instability when using community logical
expressions in the sub-policy with policy variables. [233777-MA]
DHCP • A local-dhcp-server with use-gi-address scope pool and nak-non-matching-subnet

enabled could have incorrectly not replied a DHCP NAK upon a DHCP Request for a
previously assigned address via option 50 when the address was not available and the
DHCP pool name was not part of the DHCP Request message. This issue has been
resolved. [232438-MI]
OSPF • When a next-hop segment-routing tunnel was traversing a LAN, then the calculated RLFA
segment-routing tunnel might have been installed over the same LAN, even when an
alternative segment-routing tunnel that did not go through this LAN was available. When
the LAN failed, this would have caused tunnel traffic loss until SPF had calculated and
installed the new/alternative segment-routing tunnel. This issue has been resolved.
[207891-MI]
BGP • If deterministic-med was configured, it was possible that an incorrect route would have
been installed in the RTM and the prefix was not advertised to peers. This could have
happened in cases where there were multiple MED groups for a prefix and the MED was
not compared between the MED groups for the given prefix. A workaround was to remove
deterministic-med or enable always-compare-med. [223773-MA]
• In certain scenarios, when the same IP-VPN prefix was received with different attributes, a
local policy re-evaluation might have caused BGP updates to be sent over the local VPRN
PE-CE BGP session. This issue has been resolved. [225596-MI]
MPLS/RSVP • When RSVP refresh-reduction was enabled on a tagged network interface with certain
port MTU settings, LSP flaps due to RSVP refresh timeout might have occurred. This issue
has been resolved. [224050-MI]
IP Multicast • In rare cases, sending an IGMP group-specific query on a VPLS SAP with IGMP-snooping
enabled, but which was not active because of MC-ring or multi-homing, could have
resulted in a resource leak that eventually impacted service or protocols. This issue has
been resolved. [233576-MA]

Resolved Issues
IGMP • Receiving large bursts of IGMP packets could, in very rare cases, have resulted in the
multicast FIB no longer being updated so that multicast traffic was not being forwarded to
newly-joined destinations. This issue has been resolved. [231318-MA]
PIM • Configuring auto-rp-discovery in the pim rp CLI context could have resulted in system
instability. Prior to Release 13.0.R10, this could be prevented in some networks by
configuring a PIM import policy that blocked both auto RP groups 224.0.1.39/32 and
224.0.1.40/32. In a multi-vendor network running PIM-DM, however, system instability
could still have occurred and auto-rp-discovery had to be disabled to prevent it. This issue
has been resolved. [217213-MA]
Filter Policies • Using SNMP to delete a prefix list entry that was automatically inserted through the apply-
path functionality would have left the ip-prefix-list or ipv6-prefix-list empty even if a
match existed. A workaround was to remove and then re-add the apply-path command in
the ip-prefix-list or ipv6-prefix-list. This issue has been resolved. [227109-MI]
Services General • The tmnxEqDataPathFailureProtImpact log event would not be generated if an automatic
recovery action in the datapath resulted in an ETH-CFM defect of defRDICCM. This issue
Subscriber • If both OIDs tmnxDiamApGxAvp bit 5 (nas-port bit) and

Management tmnxDiamApGxAvpNasPortBitspec are not set at the same time, which results in a
misconfiguration, an error message is now generated. Note, however, that old configuration
files cannot be read. [227858-MI]
• A PPPoE session over a LAC MLPPP bundle that failed and was then immediately retried
on the same bundle could, in rare cases, have resulted in a reset of the standby CPM/CFM.
• MLPPPoX on LNS now works correctly on 7750 SR-1e, SR-2e and SR-3e chassis.
[230591-MI]
• From Release 13.0.R10 onwards, multicast and multicast control protocol packets of a
PPPoE host that are egressing a group interface with SRRP enabled and in SRRP master
state will have the SRRP MAC address as source MAC address. Prior to this change, the
physical MAC address of the outgoing port was used which could have resulted in a drop
of the multicast traffic in the CPE. [231897-MI]
VPRN • If the amount of BGP-VPN routes received exceeded the maximum-routes threshold
configured for a VPRN, a withdraw of an installed route might not have resulted in an
existing BGP-VPN being installed even though the threshold was below the configured
maximum. This issue has been resolved. [230129-MI]
WLAN-GW • Migrant users promoted to ESM have RADIUS Request attributes only decoded when
authenticate-on-dhcp is enabled. When attributes were not decoded, this might, for
example, have resulted in an empty (00:00:00:00:00:00) RADIUS accounting Called-
Station-Id attribute. This issue has been resolved. [230287-MI]

Resolved Issues
NAT • The number of outside IP addresses used in L2-Aware NAT pools should have been
restricted to 10x256K (2621440) addresses. This issue has been resolved. [220854-MA]
• Performing a nat-pool shutdown while the standby CPM/CFM was reconciling might
have caused the standby to reset. This issue has been resolved. [230900-MA]
Application • Enabling AA URL filtering could, in rare cases, have resulted in an ISA reset. This issue
Assurance has been resolved in the isa-aa.tim file and only an upgrade of this image file is required to
prevent this issue. [232927-MA]
BFD • To interoperate with some third-party BFD implementations, the first BFD packet
transmitted was changed in Release 8.0.R2 to have “Session State: AdminDown”.
Subsequent packets were transmitted with “Session State: Down”; however, this was only
implemented for IOM-based BFD sessions. BFD sessions of type cpm-np continued to
transmit subsequent packets with “Session State: AdminDown”, which could have resulted
in some interoperability issues. This issue has been resolved. [228364-MI]
Issues Resolved in • The following table summarizes the issues that were resolved in releases prior to Release
Prior Releases 13.0.R10, but which were not documented in the SR OS Release Notes until Release
13.0.R10. Refer to the Resolved Issues section of the applicable release for details.
Table 15. Issues Resolved Earlier than Release 13.0.R10
Component Resolved Issue Release

LAG 189138-MI 13.0.R3
226191-MA 13.0.R9
VPRN 227515-MI 13.0.R9
Release 13.0.R9
HW/Platform • Certain switch-fabric errors, which, in rare cases, could have resulted in traffic impact and
egress FCS error alarms on multiple egress forwarding complexes, are now automatically
corrected. [225344-MA]
CLI • An admin disconnect command did not always stop a CLI session that had started an ssh
or telnet session to a remote device. This issue has been resolved. [221242-MI]
System • When OOB management Ethernet port redundancy was enabled and the active CPM
management Ethernet port was in a link down state, the output of the show port command
displayed the active CPM link as "UP" instead of displaying "A->B" or "B->A". This issue

Resolved Issues
• The show system switch-fabric command will now correctly display "Switch Fabric
(chassis is 200G/Slot capable)" in the table header. This is only applicable to 7750 SR-7/12
and 7450 ESS-7/12 chassis. [228630-MI]
NETCONF/YANG • Executing <edit-config> with the unsupported “replace” operation could have, in certain
cases, resulted in a High-Availability switchover. This issue has been resolved.
[229144-MA]
LAG • For Epipe services with default service queuing, and where the SDP was bound to a tunnel
whose primary path had a LAG with a different number of member ports or ECMP links
than the backup path, a Fast Reroute (FRR) switch between the primary and backup paths
could have resulted in higher-than-expected traffic loss. This issue has been resolved.
[226191-MA]
PTP • The time recovery algorithm used when the PTP profile is configured for G.8275.1 has
been adjusted to use a larger filter bandwidth, resulting in faster convergence. This aligns
with the expectations of the boundary clock bandwidth for the full-on path support time
distribution as defined by the ITU-T. [220405-MA]
• For a node configured as IEEE 1588 PTP clock type ordinary slave, it is now permitted to
set the profile to g8275dot1-2014. [228585-MI]
• An unexpected CPM/CFM reset could have occurred when IEEE 1588 PTP was operating
over an extended period of time. This reset would have occurred after 776 days of
continuous IEEE 1588 PTP operation with default message rates of 64 packets per second,
or after 388 days if any external IEEE 1588 peers or ports were using message rates of 128
packets per second. In prior releases, the CPM/CFM reset can be prevented by taking one
of the following actions prior to the expiration of above mentioned periods:
− in systems with dual CPM/CFM, enforce a High-Availability switchover, or
− in systems with single CPM/CFM, remove all PTP peer and port configuration, shut
down PTP with configure system ptp shutdown, remove all dynamic peer
information with clear system ptp inactive peers and then reconfigure and re-enable
PTP.
This issue has been resolved. [229549-MA]
SNMP • SNMP WALK and GETNEXT on the LDP tree-trace MIB table
Infrastructure “tmnxOamLTtracePathInfoTable” failed to retrieve any information. SNMP GET
succeeded only when providing a valid index.
The workarounds were as follows:
− retrieve the paths for a LDP FEC individually or by walking the MIB objects with the
FEC provided. To get the FEC, walk the “tmnxOamLTtraceFecInfo”
− execute the CLI command show test-oam ldp-treetrace prefix prefix detail to
retrieve the information from tmnxOamLTtracePathInfoTable.

Resolved Issues
DHCP • In a redundant DHCPv6 server configuration with failover mode local/remote, each server
must have a unique DUID. In releases prior to Release 13.0.R9, configuring the same
server DUID on DHCPv6 servers in failover mode local/remote could have resulted in
unused DHCPv6 server leases. Conflicting DHCPv6 server leases as a result of such a
DHCPv6 server misconfiguration are now detected, logged, and locally deleted in the
Multi-Chassis Synchronization database with an address conflict error to notify the
operator to check the DHCPv6 server configuration. [228960-MI]
OSPF • An OSPF ABR configured with originate-default-route in an NSSA and no adjacency-

check disabled would have continued to advertise a default route into the NSSA even if all
adjacencies in area 0 were "Down", as long as a loopback interface was operationally "Up"
in area 0. This issue has been resolved. [228986-MI]
• The subnet of the IP address on secondary interfaces was not being checked for
mismatches. If the interface was configured incorrectly and used in multiple OSPF areas,
then a secondary adjacency was established, which could have resulted in incorrect routing.
BGP • In Release 13.0.R9, BGP-VPN next-hops can no longer be improperly bound to a GRE
tunnel resolved by IPv4 BGP and, therefore, the BGP-VPN next-hop will remain
unresolved if GRE is the only auto-bind-tunnel option. [203849-MA]
• In Release 13.0.R9, convergence times will be reduced when there are simultaneous
multiple next-hop BGP EDGE PIC failures. [226322-MI]
BGP VPLS • In a BGP-VPLS service, if the far-end node advertised multiple VE-IDs, the lowest VE-ID
would not be consistently selected as the best. This issue has been resolved. [220104-MA]
Services General • BFD sessions on R-VPLS interfaces with hold timers less than 600 ms will no longer
bounce after a CPM high-availability switchover on nodes equipped with CPM5.
[229028-MA]
Subscriber • External downstream traffic could not reach GRT-based IPv6 unnumbered hosts, when it
Management arrived in a VPRN context with grt-lookup enable-grt and a GRT-leaking static route
matching the traffic was enabled. This issue has been resolved. [227128-MI]
IPsec • In some cases, not all 16 supported private interfaces in a single VPRN would have become
operationally up if they were exclusively associated with IPsec gateways (dynamic LAN-
to-LAN tunnels). Tunnel establishment could have failed with an error log similar to:
"Creation of an IPSec Remote-User tunnel 83.0.0.12:500 on SAP:tunnel-1.public:14,
service:102 failed because Failed to get an internal IP address." The workaround was to
configure a static LAN-to-LAN tunnel on each private interface; these static LAN-to-LAN
tunnels did not need to be operationally up. This issue has been resolved. [228008-MI]
L2TP • Starting with Release 12.0.R1, L2TP LNS incorrectly did not include all L2TP access-
loop-options AVPs in the RADIUS Access-Request message. This issue has been resolved.
[227909-MI]

Resolved Issues
VPRN • Locally-generated ICMPv6 requests from a VPRN with grt-lookup enable-grt destined to
a subscriber host in the Base router were incorrectly dropped. This issue has been resolved.
[227515-MI]
NAT • If the number of ISAs in a nat-group was decreased (shutdown, decrease active-mda-
limit, no shutdown) after an active-active nat-group was configured and the nat-group
was put in service, the show isa nat-system-resources always incorrectly displayed the
percentage of the resources used as zero (0). This issue has been resolved. [225003-MI]
• A number of L2-Aware subscribers might have been lost when shutting down two (2) ISAs
that were in an active-active nat-group or when clearing the ISAs one by one. This issue
Release 13.0.R8
HW/Platform • While performing Major ISSU, executing a configuration file from the node during the
ISSU process immediately after the IOMs completed the Soft Reset might have caused the
upgrade to fail. File transfer and other actions that required executing configuration files
should have been performed after the node had finished its upgrade. This issue has been
resolved. [205645-MA]
• On a 7950 XRS-40, cards can now be provisioned in slots 11 to 20 when there are ingress
queue-groups on two (2) or more XMAs in slots 1 to 10 with different ingress queuing
types (dynamic queues and fixed ingress queues). The tools dump system-resources
command displays the type of queuing that an XMA supports. The workaround was to
provision the cards in slots 11 to 20 before configuring any queue groups. [223763-MI]
• The show mda detail command was not displaying "MDA Specific Data" field for MS-
ISA/MS-ISA2 for the isa-video, isa-aa, and isa-tunnel applications. This issue has been
• Power-lost alarms might have been incorrectly triggered for power supplies on 7750 SR-
a4/a8 chassis. This issue has been resolved. [225059-MI]
• From Release 13.0.R1 onwards, reporting an error when the forwarding complex detected
persistent FCS errors in the ingress datapath, was not functioning properly. This issue has
been resolved. See TA 16-0290 for more information. [226501-MI]
System • On iom2-20g network interfaces, pings of IPv6 addresses initiated from an SR OS node
were not counted in the egress counters. This issue has been resolved. [192990-MI]
• Prior to Release 13.0.R8, when operating as an IEEE 1588 boundary clock, if the
Announce information from the parentClock indicated that timeTraceable was FALSE,
then the values used for the timestamps on master ports would not be time-aligned with the
timestamps received into the slave port. This is counter to the procedures of an IEEE 1588
and has been corrected. The time received into the slave port will now be propagated out of
the master ports regardless of the setting of the timeTraceable flag. [220342-MI]

Resolved Issues
CLI • After the match expression pipe command was used many times with any CLI show
command, it might have failed to execute due to an “out of memory” error. This issue has
RADIUS • The "Transaction success ratio" and "Transaction failure ratio" in the output of show aaa
radius-server-policy policy-name statistics displayed incorrect values if the total number
of requests processed was more than 42949672. This issue has been resolved. [224345-MI]
Routing • A prefix-list linked to a static route, followed by an implicit or explicit policy abort, could
have caused a node reset after the next creation of the same prefix-list when followed with
a commit. This issue has been resolved. [208340-MA]
• SNMP read operations on vRtrFibStatTable entries in the TIMETRA-VRTR-MIB could
sometimes time out under busy conditions, causing values of zero (0) to be returned instead
of the actual route count. This issue has been resolved. [214262-MI]
• A static-route was remaining active in the route-table when the next-hop interface
transitioned to an operationally down state, and there was another active non-local route
with the exact same prefix as the next-hop interface address. The workaround was to use
the option validate-next-hop for static routes that could be affected by this issue. This
issue has been resolved. [218060-MA]
IS-IS • An SNMP SET operation for the following IS-IS MIB attributes on a non-existing interface
might have caused the active CPM/CFM to reset:
− tmnxIsisIfIpv4IncludeBfdTlv
− tmnxIsisIfIpv6IncludeBfdTlv
− tmnxIsisIfDefaultInstance
• When authentication is enabled, SR OS now allows a purge TLV that contains only purge
TLVs listed in the registry, but also unlisted purge TLVs when the POI TLV is present.
[223338-MI]
• The MIB object for isisSysWaitTime in ISIS-MIB allowed values to be set that were
outside the range of accepted values. The MIB object has been updated to only permit
values of (60..1800) in the TIMETRA-CAPABILITY MIB, which is consistent with the
values in the MIB object tmnxIsisOverloadTimeout in TIMETRA-ISIS-NG-MIB.
[223974-MI]
OSPF • When an OSPF adjacency was being established and the IP address of a subnet was the
same as the neighbor’s OSPF router ID, this could have resulted in a CPM/CFM High-
Availability switchover. This issue has been resolved. [214343-MA]
BGP • Release 11.0.R4 introduced a configurable change to the BGP best-path selection
algorithm. When upgrading from a pre-Release 11.0.R4 SR OS, an issue occurred where
the configuration was not always translated correctly in the new syntax. For example,
always-compare-med zero was incorrectly changed into always-compare-med strict-as

Resolved Issues
zero and therefore resulted in different operational behavior. This issue has been resolved.
[213264-MA]
• Receiving the same route from over one thousand (1000) BGP peers in the same routing
instance no longer results in system instability. [219127-MA]
• Local routes were incorrectly being used to resolve BGP next-hops when disallow-igp was
enabled. This issue has been resolved. [219557-MI]
• The BGP peer was reset when receiving an EVPN Inclusive Multicast Ethernet Tag route
with composite tunnel type (as defined in draft-ietf-bess-evpn-etree) unless bgp>error-
handling>update-fault-tolerance was enabled. This issue has been resolved.
[223135-MA]
BGP-EVPN • The EVPN multi-homing function may not have worked correctly after the auto-generated
policies _ES_EvpnEthSegRtImp and _ES_EvpnEthSegRtExp were manually modified.
• Standby CPM/CFM synchronization may have failed after a CPM/CFM High-Availability
switchover or standby CPM/CFM reset, if the EVI was used to derive the BGP RD for a
BGP-EVPN VXLAN-based service. Also, if the EVI value and admin status were enabled
in a single SNMP SET for a BGP-EVPN VXLAN-based service and the EVI was used to
derive the BGP RD, the SNMP SET operation would have failed. This issue has been
Filter Policies • In a system with dual CPMs/CFMs and Enhanced Subscriber Management enabled, the
filter configuration on the standby CPM/CFM may have been out-of-sync with the active
CPM/CFM if all of the following conditions were met:
− host-common filter rules (or PCC charging rules with filter actions) were applied for
some hosts (resulting in the auto-creation of a shared filter)
− afterwards, one modified the base filter from which the auto-created shared filter is
created by adding embedded filters
These embedded entries were normally propagated to the derived shared filter, but this
propagation of the embedded entries was not done on the standby CPM/CFM. If a
CPM/CFM switchover subsequently occurred, those additional files, created after the
shared filter, would have been lost.
A temporary workaround was to remove the embedding (no embed-filter) and re-apply it
(embed-filter) for all base filters for which derived shared filters exist. This issue has been
Services General • The router policy statements “_ES_EvpnEthSegRtExp" and "_ES_EvpnEthSegRtImp”

were auto-created by the system for EVPN multi-homing functions and should not have
been referenced in any policy configuration in the system. This issue has been resolved.
[218217-MI]
• The CLI output line that displayed the number of maximum IPv4 routes configured for a
VPRN in show service id was inadvertently removed in Release 13.0.R5. This was a
display-only issue, and the output is also available in show router status. This issue has

Resolved Issues
• The configuration of a proxy-arp or proxy-nd anti-spoof-mac matching a previously-

configured conditional static-MAC was incorrectly allowed by the system when the
SAP/SDP-binding (on which the static-MAC was configured) was operationally down.
This issue has been resolved. To upgrade to a new SR OS release that enforces this check,
the user must first remove this configuration. [223195-MI]
Subscriber • In case of a Proxy DHCP server setup, a DHCP Request with non-matching option “DHCP
Management server address” (54) was incorrectly not dropped. This issue has been resolved.
[220912-MI]
• In a system with a dual CPM/CFM, the standby CPM/CFM might have reset if all of the
following conditions were true:
− dual IPv4/IPv6 hosts in one session were used in the system (PPPoE/IPoE session)
− host-common filter rules were applied for these hosts
− a CoA for such a dual host failed because the requested host-common rules, which
were compatible for the IPv6 host, could not be installed for the IPv4 host.
• An ESM subscriber host with QoS overrides that is not IPoE-session enabled, applied via
Diameter Gx, could have had those QoS overrides incorrectly removed upon DHCPv6
renew. This issue has been resolved. [226714-MA]
• When filtering on the host-lockout context state, sometimes all contexts were displayed
regardless of the specified context-state filter. This issue has been resolved. [226478-MI]
• If a new persistence-record was written during the same second as a wrap-around occurred
on an internal counter after approximately 497 days, a CPM/CFM switchover might have
occurred. This issue has been resolved. [227300-MI]
VPLS • cpe-ping was not supported on VPLS services where Proxy-ARP/ND was enabled. This
issue has been resolved. [219927-MI]
• In EVPN-MPLS-enabled VPLS services, received MAC routes with non-zero Ethernet
tags were processed and the corresponding MAC addresses were learned in the FDB. This
VPRN • If a labeled BGP route was received in a VPRN with an implicit-null label and the MPLS
transport (LDP or RSVP) for that VPRN was configured to also send out an implicit-null
label, traffic coming from other VPRN PE nodes over the MPLS transport toward the BGP
route was incorrectly dropped. This issue has been resolved. [224092-MI]
IPsec • IKEv1 static LAN-to-LAN tunnels using a security policy entry local-ip any or remote-ip
any remained operationally down because the system required an exact match of the peer
Traffic Selector. This issue has been resolved. [226589-MA]
NAT • Shutting down or clearing ISAs while they were being reconciled, immediately followed
by deleting L2-Aware subscribers that had subscriber-hosts or static-port forwards
associated (either explicitly or via shutting down a NAT group), could have resulted in
system instability. This issue has been resolved. [218347-MA]

Resolved Issues
• Configuration of shared ISAs between an active-active nat-group and an active-standby

nat-group should have been rejected; however, when a nat-group was configured first
with the ISAs and then information was added about the active-active feature, the
configuration may have been incorrectly accepted. This could have led to an active CPM
reset after a CPM switchover. This issue has been resolved. [225980-MI]
• NAT debug subscribers did not work for nat-group-id 4 or wlan-gw-group-id 4. This
Application • Under unexpected SIP traffic conditions, an internal resource may have been freed twice
Assurance causing a benign error message. This issue has been resolved. [179269-MI]
OAM • In Releases 13.0.R1 through 13.0.R7, if the LLDP portIdTlv is over 30 characters, which
can occur if the port-id-subtype is anything other than tx-local (default), attempting to
send an LLDP shutdown to a peer may cause a system restart. LLDP attempts to send a
shutdown message any time the admin-status changes from enable to disable. This results
from a manual configuration change of admin-status or a configuration rollback which
reverts an LLDP session to a previous disable admin-status.
Before changing the LLDP admin-status from enable to disable or performing a rollback,
LLDP should be configured to use the default port-id-subtype tx-local. The tx-local value
should not exceed 30 characters. This will prevent the system restart. [221773-MA]
Release 13.0.R7
HW/Platform • A defective XMA card with a particular hardware defect might have caused the associated
XCM card to reset in the 7950 XRS. This issue has been resolved, and now only the
defective XMA card is reset. [218769-MI]
• In some cases, a card failure triggered by the fail-on-error mechanism might have caused
more-than-expected loss of multicast traffic due to RPF check failures. This issue has been
• An iom3-xp-c can no longer be incorrectly configured on the 7450 ESS-6/6v.
[219048-MA]
• Certain types of very rare memory errors in the data path could have resulted in traffic
impact without an alarm being generated. This issue has been resolved. [219584-MA]
• When performing a minor ISSU upgrade from Release 13.0.R4/5 to Release 13.0.R6 in a
node that has a mix of EVPN destinations and regular sdp-bindings, on CPM switchover,
there was a possibility of traffic loss on some regular SDP-bindings on IOMs running the
older image until these IOMs were Soft Reset or rebooted to use the Release 13.0.R6
image. This issue has been resolved, and thus upgrading from Release 13.0.R4/5 to Release
13.0.R7 is not impacted. [219609-MA]
• A fail-on-error event on a 7950 XRS XMA could have resulted in service impact for
multicast traffic across other XMAs. This was only an issue in Release 13.0.R6 and has
now been resolved. [222322-MA]

Resolved Issues
RADIUS • If a configuration was saved with a Python policy called by RADIUS servers in the
management router instance, it may not have been possible to reload the configuration.
TACACS+ • On a system with tacplus configured as the first method under configure system security
password authentication-order, a CPM/CFM High-Availability switchover may have
occurred if Public Key method was used for user access combined with certain attributes
received from the TACACS+ server. This issue has been resolved. [220521-MA]
System • In previous releases, default log-id 99 or log-id 100 should not have been deleted then re-
created without specifying a log destination; otherwise, this could have resulted in an
invalid configuration to memory 0 after two CPM/CFM High-Availability switchovers.
Saving this invalid configuration could have resulted in a failure to execute the
configuration after a node reboot. This issue has been resolved. [216517-MA]
LAG • Depending on LACP and BFD timer settings, Layer-3 protocol Hello messages might have
continued to have been sent on the primary port instead of moving to another LAG member
port when the following conditions were met:
− uBFD was configured on a LAG
− LACP and bfd-on-distributing-only were also provisioned
− the uBFD session failed on the primary port but the physical link remained up
This issue could have resulted in protocol adjacencies to flap after their Hello timer
expired. This issue has been resolved. [218559-MA]
• During a CPM/CFM High-Availability switchover, the new active CPM/CFM now sends
out LACP packets with the configured source MAC address of the LAG instead of the
source MAC address of 00:00:00:00:00:00. After the switchover is completed, the
CPM/CFM uses the MAC address of the ports. [219707, 220031-MI]
Python • A prefix length could not be supplied using Python setEsm alc.dtc.ipv6DelegatedPrefix or
alc.dtc.ipv6SlaacPrefix. The prefix length would have been taken from another source
(RADIUS, Local User Database); if no other source was found for the prefix length, the
host setup would have failed. This issue has been resolved. [204640-MI].
DHCP • No mixed DHCP server pools for local address assignment PPPoE and plain IPoE hosts
were supported in a Wholesale/Retail dual-homed configuration. The address ranges may
not have overlapped between BNGs in case of multiple client-applications on the DHCP
server and local address assignment was used. This issue has been resolved; however,
Alcatel-Lucent recommends against mixing different client applications. [185367-MA]
• In Release 13.0.R7, anti-spoof-mac can no longer be set to the unsupported broadcast
address via SNMP. As a result, the invalid configuration statement lease-populate l2-
header mac ff:ff:ff:ff:ff:ff 128 was added to the configuration file, and rebooting the
system with this configuration would have failed.
Performing a Major ISSU from a release where the MAC address was configured with
ff:ff:ff:ff:ff:ff would also have failed, generating the following error message:

Resolved Issues
“MAJOR: CLI #1009 An error occurred while processing a CLI command - File
ftp://*:*@....cfg, Line 1160: Command "lease-populate l2-header mac ff:ff:ff:ff:ff:ff 128"
failed.” This issue has been resolved. [207995-MI]
IS-IS • Moving a system IP address from one node to another (without doing a shutdown/no
shutdown on IS-IS) could have resulted in a CPM/CFM High-Availability switchover
when a CSPF LSP was enabled on the system IP address that was moved. This issue has
• In a scaled configuration where a large number of prefixes were being leaked from L2 to
L1, it was possible that after a CPM/CFM High-Availability switchover, the L1 LSPs
would get generated without the up/down bit set for some of the leaked prefixes. This issue
BGP • PE-CE BGP sessions will now be properly established when the VPRN is configured as
type hub and the BGP session is established over the network interface regardless of
multi-hop configuration. [206171-MI]
• BGP IPv6 sessions would have flapped upon a BGP configuration change if unsupported
families were enabled over the session, such as EVPN, MVPN-IPv4, or MVPN-IPv6. A
workaround was to not enable the unsupported families for an IPv6 peer. This issue has
• The active CPM, CFM, or sometimes both CPMs or CFMs, will no longer reset in some
cases when the BGP instance is removed from a VPRN or when a VPRN with an active
BGP instance is shut down. [221153-MI]
BGP-EVPN • If the auto-bind-tunnel resolution-filter was configured with only bgp in the protocol list
and the resolution is not set to filter, then the configuration would not have appeared in the
output of the info command and would not have been saved with an admin save command
even though the configuration was active on the node. This issue has been resolved.
[219532-MA]
IGMP • The sgt-qos application mld setting was not honored for MLD packets sent out of a group-
interface in an IES or VPRN service context. This issue has been resolved. [219484-MI]
MVPN • In Rosen MVPNs with S-PMSI, when the SDP resolving traffic towards the source
bounced frequently, there was a small chance that the ingress PE was still forwarding
multicast data traffic on the I-PMSI state even when the PIM database indicated otherwise.
Duplicate traffic was discarded by the egress PE. This issue has been resolved.
[207506-MI]
Services General • Snooped frames (such as ARP) received over force-vlan-vc-forwarding enabled spoke-
SDPs would have had an extra VLAN tag when going out on other SAPs/SDPs in the
service as the VLAN tag associated with force-vlan-vc-forwarding was not correctly
stripped. This issue has been resolved. [216675-MA]

Resolved Issues
• In an EVPN all-active Multi-homing scenario, CPM-/CFM-generated BUM traffic was

treated as unicast and therefore may have been sent by the non-DF to the ethernet-
segment. This issue has been resolved. [217101-MA]
• Proxy-ARP/ND is now supported in BGP-AD provider-tunnel-enabled services.
[218415-MA]
• On the 7750 SR-a based platform, the number of SDP bindings per VPLS service has been
restored to 256. Releases 13.0.R4 to 13.0.R6 had this limit inadvertently reduced to 100.
Subscriber • In certain scenarios where L2TP tunnel accounting was enabled, it was possible for some
Management closed L2TP tunnels to become unresponsive and not be removed from the system. If the
number of unresponsive tunnels reached the maximum number of 16K L2TP tunnels per
system, new tunnels would not be created with the reason “noTunnelAvailable”. A High-
Availability switchover could have been performed to recover from such a state. This issue
• The IPoE-session session-limit value was incorrectly not enforced in case of a pd-
managed-route. This issue has been resolved. [220351-MI]
• When clearing DHCPv6 leases using the command clear service id x dhcp6 lease-state,
DHCPv6 release could not be generated using the link-address from the Local User
Database IPoE host. To have release messages generated, there needed to be at least one
prefix configured under the subscriber-interface IPv6 subscriber-prefixes or one link-
address under the group-interface IPv6 DHCPv6 relay. This issue has been resolved.
[220520-MI]
• Nodes equipped with CPM5 only supported 2,500 simultaneous HTTP redirect
connections and should have supported 10,000 simultaneous HTTP redirect connections
like CPM3 and higher. This issue has been resolved. [221299-MA]
VPRN/2547 • A CE-originated route may have been advertised to MP-BGP peers even when it was
deleted from the VRF route table and there was a less-preferred prefix that became active
in the VRF route table, even if it should have been rejected by the VRF export policy. To
withdraw the CE-originated route, the VRF export policy needed to be removed and then
re-added, or the VRF export policy had to be modified to allow and then deny the less-
preferred route. This issue has been resolved. [212815-MI]
IPsec • The output of debug ipsec tunnel or debug ipsec gateway tunnel did not display
retransmitted IKE packets. This issue has been resolved. [216923-MI]
• If two X.509 certificates with the same Subject field were used in different CA-profiles,
with crl-optional enabled on both profiles, the system was unable to remove them from the
Certificate Management module when one CA-profile was shut down. Subsequent
attempts to bring the CA-profile operationally up would have failed with log events such as
“: SECURITY #2045 Base Cert "CA profile CA-Prof1 changed state to down due to
"certificate already in store and same as in CA profile CA-Prof1""”. This issue has been
Video • An accounting policy that collected video records to a file that was located on a non-
existing or non-functional compact flash would have caused a continuous increase of

Resolved Issues
memory consumption on the CPM. In time, this could have caused the memory on the
CPM to be depleted. To avoid this issue, either the accounting policy must have pointed to
a file which was located on a functional compact flash or the policy must have been shut
down. This issue has been resolved. [209686-MI]
• In scenarios where an MS-ISA configured as isa-video was used as fcc-server or local-rt-
server, a new RTCP session creation failure, due to an out-of-memory condition, would
have triggered a CPM High-Availability switchover. This issue has been resolved.
[210592-MA]
Mirror Service • Mirroring of a PW-SAP could not be stopped once it had been started. This issue has been
NAT • Removing the NAT “inside” node using the no nat CLI command in the presence of active
deterministic classic LSN prefixes may have resulted in trace events such as
“BB:bbNatVrtrDelete This Vrtr entry still has active deterministic prefixes ...”. It was
advisable to remove all deterministic prefixes before removing the NAT “inside” node to
avoid these traces. This issue has been resolved. [206572-MI]
• When using NAT DS-Lite and using PCP to set up the port forwards, the setup failed if the
user source port was in the range from 0x6000 to 0x6FFF. This issue has been resolved.
[219769-MA]
Application • Under unexpected system messaging loss conditions, incorrect subscriber final statistics
Assurance entries may have been written into the custom-records-aa-sub accounting file. This issue
• Under unexpected fragmented SPDY traffic conditions, the ISA card may have rebooted.
OAM • When the return path resp-sdp resp-sdp-id was not specified, an OAM sdp-ping would
still have been successful when the responder node egress interface was a physical port or
channel (bundles and LAGs included), but the reply packet would still have been dropped
for other interfaces, such as a spoke-sdp interface. This issue also existed for a reply to an
sdp-mtu and a sdp-keepalive, both of which did not support specifying a return path other
than the default IP path. This issue has been resolved. [213022-MI]
Release 13.0.R6
HW/Platform • The system now reacts to an error condition detected during the initialization of the switch
fabric on SFM4, SFM5, SFM-X20-B, and SFM-X16 cards. For an integrated SFM/CPM
module the whole card will reset, while for a non-integrated SFM module the card will
remain in failed state. [208841-MI]
• When a 3HE04117AA or other dual-rate optic was installed into a p160-1gb-csfp, ma44-
1gb-csfp, or cx72-1g-csfp card, there was a possibility that the optics could stop working
over time. This issue has been resolved. [213947-MA]

Resolved Issues
• 100GE ports on the x4-100g-cfp2 XMA connected to a WDM Multiplexer will no longer
get blocked in the down state when a far-end failure occurs but a Loss of Signal (LOS) is
not locally detected. [214247-MA]
• On the 7750 SR-a4/a8, the system always reported a switch-fabric capacity of less than
100%. When the chassis log event tmnxEqLowSwitchFabricCap was configured to the
generate state, shortly after boot up, the following alarm would have been generated: “The
switch fabric capacity is less than the forwarding capacity of IO Module due to errors in
fabric links.” This issue has been resolved. [215206-MI]
• Upgrading a 7750 SR-a4/8 to SR OS Release 13.0.R5 could have resulted in CPM and
IOM cards with certain firmware versions to go into an infinite boot cycle. This issue has
• A false hardware alarm could have been generated for an XRS XMA card immediately
after the card was inserted into an XCM if the XMA card that was previously inserted in
the same slot had experienced such a hardware alarm. This issue has been resolved.
[217002-MI]
• A very rare hardware condition could have impacted the assignment of multicast planes in
the system which could have impacted multicast traffic. This issue has been resolved.
[218337-MA]
System • CPM-originated control packets that contained data errors were incorrectly forwarded to
the MS-ISA/MS-ISA2 card control plane. This could have resulted in missing information
in show commands that retrieve information from the MS-ISA/MS-ISA2 and resulted in
the following alarm being generated: CRITICAL: LOGGER #2002 Base
A:PMGR:UNUSUAL_ERROR "Slot A: pMgrRequestIpsecMdaDpStats:
iccSendRequest() to slot/mda=3/2 id=513398843 sock=74 failed with error=3 !". This
• Bringing up the router when having hold-time down configured on system-level or VPLS-
level interfaces did not trigger the expected delayed operational state. This issue has been
• Displaying an empty log (configured with “log to file”) with show log log-id x ascending
will no longer result in a CPM/CFM High-Availability switchover. This issue only existed
in Release 13.0.R4 and Release 13.0.R5. [218924-MA]
LAG • A Multi-Chassis (MC) LAG will no longer get into an unexpected state if MC
synchronization messages are lost under certain circumstances between the two MC nodes.
[215147-MI]
PTP • PTP port-based timestamping is now supported on ports when an iom3-xp-b is provisioned
as an iom3-xp. [215532-MI]
Routing • The ARP table of the management router instance did not get updated upon receiving a
gratuitous ARP. This issue has been resolved. [210882-MI]
• The output of show router x route-table summary could have showed an abnormally
high, incorrect number of host routes. This issue could have been triggered when only

Resolved Issues
changing the IP subnet mask of an interface IP address and afterwards changing it back to
the original IP subnet mask value. This issue has been resolved. [212846-MI]
DHCP • Enabling lease-populate with the route-populate keyword on regular IPv6 service
interfaces in a DHCPv6-relay context caused IA_PD/IA_NA leases to be double-counted
in the lease-population counter, which resulted in the lease-populate limit to be reached
sooner than expected. This issue has been resolved. [195537-MI]
• With DHCPv4 relay-proxy enabled on a group-interface, DHCPv4 Python scripts at the
DHCP Relay egress were not executed for unicast Release, Inform and Decline DHCPv4
client messages towards the server in either of the following cases:
− siaddr-override was enabled on the relay-proxy
− the DHCPv4 server was a local-dhcp-server in the same routing instance
IS-IS • The MTU calculation for an IS-IS segment routing (SR) tunnel now correctly accounts for
the label stack pushed by the LFA or remote LFA backup next-hop. The formula is:
SR_Tunnel_MTU (bytes) = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- 4 labels*4}, where:
− Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within a given
IGP instance using configure router isis instance-id segment-routing tunnel-mtu
value command. If no value was configured by the user, the SR tunnel MTU will be
fully determined by the IGP interface calculation explained next.
− IGP_Tunnel_MTU is the minimum of the IGP interface MTU among all the ECMP
paths or among the primary and LFA or remote LFA backup paths of this SR tunnel.
[213670-MI]
• The Traffic Engineering (TE) router ID is now correctly populated in the TE database when
the first bit of the fourth byte of the system-ID is set to 1. For example, a system-ID of
0000.0080.0000 would no longer result in this issue. [215957-MI]
OSPF • Receiving an update from a neighbor with an external LSA would have resulted in the
aggregate summary LSA for that same prefix to be withdrawn. This issue has been
• If multiple OSPF adjacencies that existed between two (2) routers and two (2) or more
links with different costs failed simultaneously but with some adjacencies intact, then
OSPF might haven take longer than expected to converge. This issue has been resolved.
[210380-MI]
• The MTU calculation for a OSPF segment-routing tunnel now correctly accounts for the
label stack pushed by the LFA or remote LFA backup next-hop. The formula is:
SR_Tunnel_MTU (bytes) = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- 4 labels*4}, where:
− Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within a given
IGP instance using configure router ospf instance-id segment-routing tunnel-mtu
value command. If no value was configured by the user, the SR tunnel MTU will be
fully determined by the IGP interface calculation explained next.
− IGP_Tunnel_MTU is the minimum of the IGP interface MTU among all the ECMP
paths or among the primary and LFA or remote LFA backup paths of this SR tunnel.
[213833-MI]

Resolved Issues
BGP • A Route Reflector with enable-rr-vpn-forwarding configured will no longer release a

label when a VPN route update is received from a peer. [216506-MI]
• Executing a BGP group export could have caused policies 6 and higher in large chains
(above 5 policies), to not be synchronized to the standby CPM/CFM after a CPM/CFM
High-Availability switchover. This issue has been resolved. [216875-MI]
BGP-EVPN • When exporting EVPN-installed IP routes from RTM to non VPN-IPv4/v6 families, BGP
did not apply export policies based on route tags. This issue has been resolved.
[214987-MA]
• In a BGP-EVPN service, when proxy-arp or proxy-nd was enabled in combination with
bgp-evpn mpls force-vlan-vc-forwarding, ARP and ND traffic was not forwarded as
expected. This issue has been resolved. [216552-MA]
IP Multicast • Multicast CAC (MCAC) limits that were configured on a group-interface were not taken
into account when per-host-replication was configured. This issue has been resolved.
[215172-MA]
QoS • On the 7750 SR-a4 and 7750 SR-a8, high- and medium-priority traffic could have been
incorrectly discarded when the router received exactly equal amounts of high-, medium-,
and low-priority traffic at a continuous 10G line rate for more than 30 seconds on three out
of four ports on a 4-port 10GE SFP+ MDA-a XP. This issue has been resolved.
[213546-MI]
• The WRED buffer allocation pool size could have been wrongly calculated if buffer-
allocation configuration was done while the wred-queue-control was in a no shutdown
state. This issue has been resolved. [215517-MI]
Filter Policies • When an IPv4 filter with an entry using egress-pbr with action forward redirect-policy
(where redirect policy had no router instance configured) was applied in a VPRN service,
PBR was performed in the Base instance instead of the VPRN instance of the incoming
interface where the filter policy was deployed. This issue has been resolved. [212063-MI]
Services General • When configuring an EVPN ethernet-segment, a route-distinguisher needed to be

configured at config>service>system>bgp-evpn so that the ethernet-segment could be
no shutdown. This issue has been resolved, and now a route-distinguisher is created
automatically if not configured. [205435-MI]
• In an all-active EVPN multi-homing scenario with aliasing, the unicast traffic from a
remote PE (that resolved the known unicast traffic for a given MAC to a given next-hop)
could have been black holed if the destination MAC was on the ethernet-segment but
there was no FDB entry for it in the non-DF PE. This issue has been resolved. [205436-MI]
• MAC-move did not detect moves between I-VPLS access SAPs/SDP-bindings and B-
VPLS EVPN-MPLS destinations. This issue has been resolved. [214217-MI]
• Router policy configurations created by VSD in the Fully-Dynamic model would have
been removed after a CPM/CFM High-Availability switchover. The use of route-targets at
service level (instead of router policies) was recommended to avoid this issue. This issue

Resolved Issues
• Querying VPLS FDB entries in scaled setups through CLI or SNMP could have resulted in
an active CPM/CFM reset. This issue has been resolved. [215989-MA]
Subscriber • In some cases when MLPPP was enabled on the LNS and an MLPPP error occurred, taking
Management a Tech Support file would have caused the MS-ISA/MS-ISA2 cards to reset. This issue has
• Using SNMP, an IPoE host could have been incorrectly configured in a Local User
Database (LUDB) with a WPP portal service-ID but without a WPP portal name. Saving
such a configuration resulted in a configuration file that could not be executed. This issue
• An MLPPPoX bundle over L2TP could have dropped upstream traffic on the LNS node
after out-of-sequence MLPPPoX packets were received. This issue has been resolved.
[216011-MA]
VPLS • Incoming Broadcast/Unknown/Multicast (BUM) VPLS traffic that was associated with
expedited policers could have been dropped after a CPM/CFM switchover if there was an
active mcast-management bandwidth-policy name that set the amount of secondary
paths to a higher value than the default of one (1). This issue has been resolved.
[214451-MA]
NAT • If a nat-group was configured and brought in service with bulk SNMP updates, the route-
table was not updated correctly, and subscribers were not present in the show command
output when deterministic prefixes were defined. In non-deterministic configurations, there
could have been an issue with the traffic. This issue has been resolved. [214499-MI]
• In a scaled-NAT subscriber setup, the performance has been improved to clear few or many
NAT subscribers. [218527-MI]
Application • When Application Assurance Redundancy Protocol (AARP) between two nodes was used
Assurance in a Security Gateway deployment, proper asymmetry removal was not guaranteed. This
OAM • When using port facility MEPs, a port shutdown event may have caused the MEP to clear
its fault for a brief period of time (CCM interval x 3.5) very shortly after declaring a fault.
The fault was declared again after this brief period of time. This issue has been resolved.
[205931-MI]
• If a port was brought operationally down due to excessive CRC errors or internal errors,
ETH-CFM would still have sent CCM packets on the port indicating that the port MEP is
up. This only occurred for sub-second CCM-enabled port MEPs and, for the Layer-2
network, could have led to blackholing user traffic. This issue has been resolved.
[213293-MA]
• The ttl-propagate parameter to enable ICMP-tunneling did not not function correctly after
two CPM/CFM High-Availability switchovers. The workaround was to toggle the ttl-
propagate configuration statement. This issue has been resolved. [216294-MI]
• OAM lsp-ping and lsp-trace may have failed in certain cases where more than one RSVP
path existed with different negotiated MTU values when a packet size close to MTU was

Resolved Issues
specified. This was only an issue with the OAM command and not with data traffic. The
following error was seen: "Packet size too big." This issue has been resolved. [216677-MI]
Release 13.0.R5
HW/Platform • When the power-supply type was configured as ac single, the “power supply x failed or
missing” error would have been triggered. The alarm was incorrectly considering the state
of a non-existent second rectifier. This issue has been resolved. [210758-MI]
CLI • Changes made to the candidate configuration are now logged in both syslog and
RADIUS/TACACS+ accounting. [214021-MA]
System • SR OS retains a history of script executions (CLI scripts used by cron or EHS) in the
smRunTable (DISMAN-SCRIPT-MIB). The table has a maximum size of 255 entries.
Entries are removed from the table when the max-completed or expire-time thresholds (as
configured in the associated script-policy) are exceeded. Prior to Release 13.0.R5, if the
table became full, then subsequent script launch requests were discarded. This behavior has
been corrected so that the oldest completed entry is removed when a new script launch
request occurs. [197634-MI]
• When PTP was enabled over certain multi-speed ports (for example, ports with electrical
SFPs), some actions on those ports could have resulted in a 3.5 micro-second Time Error
jump between the clocks that were kept synchronized over this PTP peer. This issue has
• When rollback resulted in an interface being removed from a protocol or deleted, it may
have caused the control-plane protocol to unnecessarily restart. This issue has been
resolved. [213739, 214449-MA]
LAG • When removing an mc-lag configuration, it was possible for the port to remain down with
the reason “lagMemberPortStandby”. This occured if MC-LAG was not shut down before
attempting to remove the mc-lag configuration. To avoid this, the MC-LAG had to be shut
down prior to removing the LAG from the mc-lag configuration, or the port had to be
removed from the LAG prior to modifying the mc-lag configuration. This issue has been
NETCONF/YANG • The alu-conf-router-bgp-r13.yang file was incorrectly reporting the range of the dynamic-
peer-limit-id leafs as 1..65535 (as was CLI). This has been corrected in Release 13.0.R5 to
1..8192. [207323-MI]
DHCP • When the dhcp>relay-proxy>siaddr-override ip-address value was the IP address of a

loopback interface, the saved configuration file failed to execute after a node reboot. A
workaround was to manually edit the saved configuration. This issue has been resolved.
[212027-MI]

Resolved Issues
Routing Policies • The value for an as-path within an as-path-prepend policy condition could not exceed
65535 in a policy action accept statement when supplied as a configured parameter. This
IPv6 • ICMPv6 Neighbor Solicitation messages with a Link-Local source IPv6 address and a
destination IPv6 interface address will no longer be discarded when uRPF is enabled under
the IPv6 interface. This caused a rare interoperability issue with a third-party router which
expected a Neighbor Advertisement in response to such a Neighbor Solicitation. [205524-
MI]
OSPF • OSPF running in a VPRN instance did not export a BGP-VPN route if an external LSA for
the same route was received from a CE router. Exporting the BGP-VPN route should only
have been be blocked if sham links are configured in the VPRN OSPF instance. This issue
• When segment routing was shut down on the ABR, depending on the load, the Extended
Prefix LSAs were not always properly flushed. After segment routing was enabled again,
these stale LSAs triggered unexpected events on the standby CPM during reconcile or
while it was becoming active. This issue has been resolved. [211470-MA]
• Remote LFA protection may have been lost whenever a summary LSA update resulted in
an incremental SPF. This was corrected by the next full SPF or by starting a full SPF
manually using the tools perform router ospf run-manual-spf command. This issue has
• Toggling option compatible-rfc1583 when an area-range was configured might have led
to incorrectly withdrawing the summary LSA for the area range. This issue has been
BGP • Enabling advertise-inactive under the global BGP configuration could have resulted in
some prefixes not being correctly exported to all peers. If there was an export policy in
some groups to reject the inactive prefix, it may have resulted in that same prefix not being
exported to all peers that had an export policy to accept that prefix. This issue has been
• A route selected based on the next-hop cost may not have been the best if the same prefix
was being received by multiple peers P1, P2 and P3 and the next-hop for the prefix
received from P1 and P2 are the same. The incorrect best route may have been selected if a
metric change resulted in the metric for the next-hop to be greater for P1 and P2 than P3.
• BGP may have improperly sent route-refresh messages when certain already-configured
policy actions were re-executed via CLI. This issue has been resolved. [212083-MA]
• A node that had local VPRNs configured could have had issues in forwarding IP-VPN
routes to its BGP peers if all of the following conditions were met:
− the node was configured as either a Route Reflector with next-hop-self and enable-
rr-vpn-forwarding, or as an ASBR with inter-AS option B/C
− transport-tunnel mpls or rsvp-te was used in the base BGP instance
− a new local VPRN with BGP enabled was created, or BGP was administratively
toggled in an existing local VPRN.

Resolved Issues
A workaround was to remove and then re-add the transport-tunnel under the base BGP
configuration. Refer to TA 15-0958 for more information. This issue has been resolved.
[212295-MA]
BGP-EVPN • When EVPN multi-homing was used in a PBB-Epipe service with two (2) active SAPs, a
CPM/CFM switchover may have caused the traffic to be discarded. This issue has been
LDP • The output of the tools dump router ldp memory-usage CLI command could have
incorrectly contain negative values. This issue has been resolved. [138848-MI]
• The graceful-restart capability information in the show router ldp session command
output could have been displayed incorrectly after a CPM/CFM High-Availability switch-
over. This was only a display issue without functional impact and has now been resolved.
[212828-MI]
PIM • Attempting to modify the BGP next-hop of an MVPN route by means of a policy may have
resulted in a High-Availability switchover. Note that changing the next-hop of MVPN
routes is against RFC 6514. This issue has been resolved. [205916-MI]
QoS • For self-originated management traffic such as TACACS+ or FTP, TCP packets with the
RST flag set and a window size of zero (0) were not marked as per sgt-qos setting and
instead marked as NC1. This issue has been resolved. [204736-MI]
• Higher-priority egress traffic on a 1-port 10 Gbs HS-MDAv2 could, in some cases, get
lower-than-expected throughput in case of congestion. This issue has been resolved.
[211578-MA]
Filter Policies • Configuring or modifying the ESI PBR filter entry action forward esi sf-ip vas-interface
router may have resulted in a reset of pbr-down-action-override configuration to default
on the inactive CPM/CFM. It was recommended to reconfigure pbr-down-action-
override after the action configuration change to avoid the issue. This issue has been
• De-associating a filter policy embedding a filter that contains entries with egress PBR
actions may not free egress PBR unique destination resources used in the embedded filter
properly. The issue has no impact if the egress PBR destinations from embedded filter are
used on other subscribers/host/SAPs, but could result in premature resource exhaustion.
[214725-MA]
Services General • In very rare cases, the active CPM/CFM may have reset if the forwarding of a DHCP-
snooped packet failed. This issue has been resolved. [212822-MI]
• In a PE with a significant number of EVPN-MPLS (TEP, label) destinations, after a
CPM/CFM switchover, the new active CPM/CFM may take a long time before it becomes
fully active. This issue has been resolved. [214356-MA]

Resolved Issues
Subscriber • When a node experienced a high rate of DHCP overrides, some of the overrides could have
Management failed, causing a memory leak in the “IP Stack” and “Subscriber Mgmt” pools. Over time,
this could have caused the active CPM/CFM to run out of memory, which could have been
recovered by performing a High-Availability switchover. This issue has been resolved.
[209325-MA]
• The system could have become unstable when changing the sla-profile of a host while Gx
pcc-rules were active in the sla-profile instance. This issue has been resolved.
[209628-MA]
• When specifying an egress Gx pcc-rule with the from field set to any (that is, permit out
ip from any to 20.1.1.2), no address would have matched the rule. A workaround was to
use 0.0.0.0/0 instead of the any keyword. This issue has been resolved. [211719-MI]
• In a High-Availability (HA) setup, the standby CPM/CFM could not save the configuration
for the shcv-policy under the group interface. As a result, this function was lost after a
High-Availability switchover occurred. This issue has been resolved. [213454-MA]
VPLS • When using ssm-translate with a routed VPLS service, if a (*,G) join is received in the
VPLS and translated to an (S,G) to be sent to the IP side of the service, the related multicast
stream will be forwarded correctly; however, if the same (*,G) is received on a SAP or
mesh-/spoke-SDP on a different forwarding complex, then the multicast stream will be
discarded. This issue has been resolved. [211398-MA]
IPsec • Static routes that pointed to static LAN-to-LAN tunnels configured with auto-establish
would have become inactive after the primary MS-ISA/MS-ISA2 came back online after
resetting, if the tunnel group had a backup MS-ISA/MS-ISA2. To recover and re-activate
the static routes, the tunnel had to be re-established (for example, cleared with CLI). This
• Receiving an unknown Vendor-ID payload in a create child SA message during the IKE SA
(phase-1) rekey initiated by the 7750 SR could have caused the MS-ISA/MS-ISA2 to reset.
The preventive workaround was to configure ipsec-responder-only on the tunnel group
and/or have much longer IKE SA lifetime (isakmp-lifetime) on the 7750 SR side. This
• The command show ipsec gateway tunnel private-address-type ipv4 incorrectly
displayed dynamic LAN-to-LAN tunnels. This was not correct because IP addresses are
not configured on the private interface of the gateway, and only remote-access tunnels need
IPv4/IPv6 configuration on the private interface. This issue has been resolved.
[212160-MI]
• IP filters were not programmed on a tunnel SAP after a node reboot or after
administratively toggling the operational state of MS-ISA/MS-ISA2 with shutdown/no
shutdown. This issue has been resolved. [212241-MI]
• An IPsec SA (phase-2) would not be deleted right after a Dead Peer Detection (DPD)
timeout if the UDP source port of the ISAKMP messages sent by the client was not equal to
500 and NAT traversal was disabled in the IKE policy; however, the IPsec SA would
eventually have been deleted when its lifetime expired. This issue has been resolved.
[213306-MI]
• The RA tunnel type was not properly restored on the MS-ISA/MS-ISA2 of the MC-IPsec
standby chassis when LAA/DHCPv4/DHCPv6 was used as address assignment method

Resolved Issues
and auth-method was configured as psk/cert-auth. This issue has been resolved.
[215433-MI]
PBB • Configuring via SNMP OID svcEpipePbbBvplsDstMacName without providing a valid

value for OIDs svcEpipePbbBvplsSvcId and svcEpipePbbSvcISID could have resulted in a
CPM/CFM switchover. This issue has been resolved. [211873-MA]
WLAN-GW • WLAN-GW did not support GTPv1 Create-PDP-Context-Response that contained a

Protocol Configurations Options (PCO) IE with multiple containers; only the values part of
the first PCO container were used. This issue has been resolved. [200946-MI]
• WLAN-GW GTP memory resources could have been leaked when a UE setup failed while
processing a “create session request”, (i.e., because of a pending delete). When the
WLAN-GW event “Could not initiate GTP uplink: OutOfResources” was generated due to
memory depletion, a CPM High-Availability switchover had to be enforced to restore
service. This issue has been resolved. [208017-MA]
• The debug wlan-gw gtp output could have incorrectly displayed “UnexpectedMsgType”
as root cause of GTP_UPLINK_DISCONNECTED event, while this actually should have
been “ErrorIndicationMsgRcvd”. This issue has been resolved. [209916-MI]
NAT • Continuously creating NAT dynamic port-forwards with PCP while toggling the nat-group
three or more times could have resulted in system instability. This issue has been resolved.
[211156-MA]
• The event message “tmnxNatPlLsnMemberBlockUsageHigh” contained a wrong member
ID for redundancy active-active configuration. This issue has been resolved. [212039-MI]
• When enabling an active-active NAT group, only members assigned to operationally up
MS-ISAs/MS-ISA2s would have been made active. This issue has been resolved.
[212525-MI]
Application • When an admin application-assurance upgrade command was performed on the 7750
Assurance SR-c4/c12 platforms, the ISSU state was not entered (as indicated by an ISSU operational
state on the show mda output), and the two (2) hour clear timer was not started (clear timer
is applicable to the 7750 SR-c12 only). This issue has been resolved. [198341-MI]
• Partition-level protocol accounting statistics would not collect statistics for new protocols
introduced as a result of an AA only ISSU. Performing a shutdown then a no shutdown of
protocol statistics on the affected partitions would trigger the collection of statistics for the
new protocols. This issue has been resolved. [209626-MI]
• Under unexpected Microsoft Lync traffic conditions, the MS-ISA/MS-ISA2 may have
raised a trace event or rebooted. This issue has been resolved. [212346-MA]
BFD • On initial setup, enabling micro-BFD on one end only of a LAG, using default setting max-
setup-time infinite, will no longer cause the interface that is associated with the BFD-
enabled LAG to bounce. [211616-MI]

Resolved Issues
OAM • The oam svc-ping command in Releases 13.0.R1 through 13.0.R4 was incompatible with
all other releases of the oam svc-ping command. Executing the oam svc-ping command
from/to these SR OS versions to/from a version not contained in this range will result in the
reporting of an incorrect service type and cause the command to report the test as failed.
This applied to R-VPLS, VPRN, Ipipe, Cpipe and mirrored destination service types. The
Release 13.0.R5 version of the oam svc-ping command is compatible with all pre-existing
versions of the function except for Releases 13.0.R1 through 13.0.R4. [188315-MI]
• Memory usage in the MPLS/RSVP memory pool could have steadily increased due to a
memory leak on nodes with ETH-CFM objects configured and with SAA tests
continuously running over these objects. See TA 15-1020a for more information. This issue
Release 13.0.R4
HW/Platform • The transmit (TX) laser of a GigE SFP would have remained on regardless of the
administrative state of the port if an operational SFP (Link up) was swapped with a
defective SFP (for example, an SFP that was unable to be brought up due to bad
checksum). To disable the laser, a known functioning SFP needed to be inserted. This issue
• In rare cases, an XMA was not detected after being inserted into an active XCM in a
7950 XRS chassis. The workaround was to reinsert the XCM. This issue has been resolved.
[203984-MA]
• In certain scenarios, a new multicast stream could have been blackholed for up to 10 ms
before it was added to a multicast management path. This issue has been resolved.
[205685-MI]
• The port on p1-100g-tun or p1-100g-tun-b could have remained operationally down after a
link problem where, under certain conditions, the receiver did not lock properly to the
incoming signal. This issue has been resolved. [206008-MI]
• In Releases 13.0 R1, R2, and R3, it was possible to construct a configuration which scaled
LAG, APS, CCAG, IPsec groups, VMDA groups, and NAT groups such that the number of
chassis MACs required exceeded the number actually available. This is now resolved by
allocating chassis MAC addresses dynamically for these applications and the system now
enforces a chassis MAC limit. Attempting to create one of the above objects will fail if
there are insufficient available chassis MAC addresses.
This means that it is possible to construct a configuration file in Releases 13.0 R1, R2, and
R3 which does not load in Release 13.0.R4 or later. Any customer who has deployed
Release 13.0.R1-R3 with a scaled number of the above objects should validate that their
configuration file loads successfully with the new software release before performing an
upgrade. Contact your Alcatel-Lucent representative for help on validating configuration
files.
The dynamic allocation algorithm can result in non-persistent MAC addresses across
reboot, and actual MAC address assigned to a particular application could change. If per-
sistent MAC addresses across reboot is required, then persistent indexes should be enabled
in the BOF with the statement “persist on”. [206135-MA]

Resolved Issues
• On a CPM5 that was becoming active due to a High-Availability switchover or at node

startup, the Power LEDs corresponding to installed power modules may have, for a
moment, incorrectly flashed amber before correctly turning green. This issue has been
• Prior to Release 13.0.R4, the Minimum/Current/Peak values in the wattage information in
the output of show card x detail on a 7950 XRS chassis reflected the power consumed by
the XCM and its XMAs while the Max. Required value represented only the XCM
maximum required power. This issue has been resolved. [206709-M]
• The output of show card detail may not always have displayed the source of detected FCS
errors. This issue has been resolved. [209479-MI]
RADIUS • RADIUS proxy cache population through “track-mobility” is now limited to RADIUS
proxy cache scale. [205963-MA]
System • On 7750 SR-c4/c12, the value displayed for “Filters avail” when executing tools dump
filter resources iom and the values of the SNMP objects tFPResIngAclFilterTotal and
tFPResEgrAclFilterTotal were always incorrectly displayed as zero (0). This issue has been
• After successfully performing a file move operation using an FTP location as the source,
the following error message was displayed: “MINOR: CLI This command is not supported
for non-local FTP or TFTP URLs”. This issue has been resolved. [202969-MI]
• When a Compact Flash is in a failed state, all subsequent transactions will now fail
immediately rather then continue to attempt to read/write. [205799-MI]
• In Release 13.0.R1, a new feature was added to allow operators to block traditional line-by-
line (immediate) configuration changes in the running configuration to enforce the use of
candidates (transactions) for configuration changes via CLI. Enabling this feature caused a
configuration execution failure after a node reboot. A workaround was to enter the
configuration as a candidate manually and then commit it. NETCONF <edit-config>
requests and the CLI commands exec and rollback revert were similarly impacted. This
• A High-Availability switchover will no longer occur when the file repair command is
executed on a corrupted compact flash. [207132-MA]
• When the log destination was a file, issuing the CLI command show log log-id x specifying
a Severity, Application, Router, or Subject would not display filtered results as expected.
• In rare cases, the following false alarm was generated for Ethernet MDAs where Sync-E
was not configured. xxx xxx/xx/xx xx:xx:xx.xx xxx CRITICAL: LOGGER #2002 Base
5:MDADRV:UNUSUAL_ERROR “Slot 5: bridgeCheckSonetClkChange: MDA 5/2: Both
clock selects asserted”. This issue has been resolved. [207883-MI]
• When transferring files using SCP with the -p option for preserving the timestamp from the
original file, the timestamp of the file would incorrectly have been sent according to the
local time zone set on the node instead of UTC. This would have caused the timestamp on
the destination to be incorrect if the local time zone set had an offset different than zero (0).
• After a High-Availability switchover, a PTP slave port might have sent a large burst of
delay request packets to its parent clock. This would have occurred if the slave clock and

Resolved Issues
parent clock were communicating using raw Ethernet/PTP packets. This issue would not
occur when the slave clock and parent clock were communicating via IPv4/UDP/PTP
packets. This issue has been resolved. [211319-MA]
Routing • In certain scenarios where multiple tunnels to the same endpoint address were used, some
only for LDP-over-RSVP and some only for IGP-shortcut, the IGP may have selected an
incorrect tunnel. This could have impacted LDP-over-RSVP and/or IGP-shortcut
resolutions. OSPF and IS-IS were both affected by this issue. This issue has been resolved.
[200750-MA]
• The output of show router x route-table summary could sometimes have shown an
abnormally high, incorrect number of routes. This issue has been resolved. [201126-MI]
DHCP • A local-dhcp-server with use-pool-from-client set could have incorrectly replied a DHCP
NAK upon a renew DHCP Request without Option 82 Vendor-Specific dhcpPool
information populated. This issue has been resolved. [207661-MI]
IS-IS • In IS-IS, the configuration export-limit n could have (depending on the export policy)
limited the number of exported IS-IS routes to n -1 instead of n. This issue has been
• The output of the show router isis status command may have displayed an incorrect
number of IS-IS “Total Exp Routes” for Level 1 and Level 2. This could have had an
impact on the routes that were actually exported in IS-IS. This issue has been resolved.
[180100-MI]
• IS-IS will no longer continuously flap if the underlying transmission network connecting
the IS-IS nodes has issues such as Layer-2 loop. [205800-MA]
• An IS-IS adjacency would have toggled if the BFD session associated with the adjacency
had not been created, which may have been the case when exceeding the BFD scaling
limit; for example, more than 500 pps (50 sessions of 100ms timers each) for BFD sessions
of type iom. For a greater number of BFD sessions, it was recommended to use BFD
sessions of type cpm-np, which have a much higher scaling limit. This issue has been
• Exporting an aggregate route or static route into IS-IS that had the same IP-prefix/mask of
an IS-IS summary-address might have caused a High-Availability switchover when the
route was added or deleted. For more information, refer to TA 15-0914. [210817-MA]
OSPF • The following display commands no longer consume memory which is never released:
− show router router-instance ospf ospf-instance opaque-database when followed by
the parameters adv-router router-id or ls-id
− show router ospf capabilities
A CPM/CFM High-Availability switchover was required to free up the memory if these
commands were executed many times and consumed a substantial amount of memory.
[211075-MI]

Resolved Issues
BGP • If BGP update-fault-tolerance was enabled in combination with loop-detect drop-peer,

detection of an AS_PATH loop would incorrectly result in error-handling behavior instead
of dropping the BGP peer. In addition, removing the update-fault-tolerance CLI
statement afterwards could have resulted in a standby CPM/CFM reset. This issue has been
• When a local route matched a policy used in vsi-export and it was advertised as EVPN or
L2-VPN route, if the route was later modified so that it was rejected by the policy, the route
would not be withdrawn. This issue has been resolved. [206637-MA]
• When a BGP route that was contributing to an aggregate route was withdrawn, the
attributes of the contributing route were not removed from the aggregate route. This issue
• Removing and creating VPRN services when BGP route damping was enabled on the
BGP-VPN peers from which the VPRNs received their routes could have, in rare cases,
resulted in an active CPM/CFM reset. The workaround was to remove BGP route damping
before VPRN services were removed/created and add it back later. This issue has been
BGP-VPWS • In a single-homed BGP-VPWS scenario, re-evaluating a PW template using the command

tools perform eval-pw-template policy-id allow-service-impact after changes to its SDP
include/exclude statements would have succeeded, but the recreated BGP-VPWS PW
would have lost any operational group association, BFD status or endpoint association. If
the same re-evaluation was performed in a dual-homed BGP-VPWS scenario with two
signaled PWs, the command would have failed with the error message “The service cannot
support any more SDP bindings”. One of the PWs would have been recreated, but would
have lost the operational group association, BFD status, and endpoint association, while the
other PW would not have been recreated at all. This issue has been resolved. [206357-MI]
LDP • An SR OS node’s LDP GR-helper functionality to a neighboring third-party router, which

was undergoing LDP graceful restart, would fail in Release 13.0.R1 to 13.0.R3 in a
scenario where the neighboring third-party router initially had sent a recovery time of zero
(0) in the FT session TLV. This issue has been resolved. [210488-MA]
• An SR OS node acting as LDP GR-helper to a neighboring third-party router, which is
undergoing LDP graceful restart, will now retry longer to set up a new TCP session when
the neighboring router with a router-ID lower than SR OS node’s router-ID is not
immediately ready to accept a new TCP session after sending out LDP hellos.
[210855-MA]
IGMP • It was possible to configure R-VPLS on an interface which also has MLD configured,
although this was currently not supported and could have resulted in a configuration that
could not be executed after a node reboot. To prevent this issue, either R-VPLS or MLD
had to be removed from the interface. This issue has been resolved. [204999-MI]
PIM • A scaled network with IS-IS LFA enabled, combined with many link flaps that resulted in
next-hop updates, could have caused PIM (*,G) groups to become unresolved while a valid
route existed in the route-table. This issue has been resolved. [202084-MA]

Resolved Issues
NETCONF/YANG • The alu-conf-svc-ies-subif-r13.yang and alu-conf-svc-vprn-subif-r13.yang files now have

the correct range for the PPPoE session-limit leaf. [179179-MI]
• The alu-conf-router-dhcps-r13.yang was incorrectly modeling DHCP/local-DHCP-
server/failover/startup-wait-time as a list. As of Release 13.0.R4, this has been corrected to
be modeled as a container. [201198-MI]
• The alu-conf-svc-vprn-if-r13.yang file was incorrectly using encryption-key as a list key
for the security-association list. This has been corrected in Release 13.0.R4. [201198-MI]
• The alu-conf-qos-r13.yang file was incorrectly modeling fp-redirect-group as a container.
As of Release 13.0.R4, this has been corrected to be a list. [201891-MI]
• The alu-conf-log-r13.yang file was incorrectly reporting the length of the
log/filter/entry/match/message/pattern string as 1..4096. This was corrected in Release
13.0.R3 to 1..400. [203085-MI]
• A number of objects incorrectly appeared in the Release 13.0.R1, 13.0.R2, and 13.0.R3
YANG files. These objects were not supported in those releases and accidentally appeared
in the YANG files. These objects included:
− alu-conf-calltrace-r13.yang: module should not have appeared until Release 13.0.R4
− alu-conf-router-bgp-r13.yang and alu-conf-svc-vprn-bgp-r13.yang: dynamic-
neighbor and dynamic-peer-limit
− alu-conf-router-pcep-r13.yang: module should not have appeared until Release
13.0.R4
− alu-conf-qos-r13.yang: the dynamic-policer containers under SAP-egress and SAP-
ingress (this did not change, but should not have been included prior to Release
13.0.R4). The slope container under queue-group-templates/egress/queue-
group/policer and SAP-egress/policer.
− alu-conf-service-r13.yang: a number of nodes under the service-carving container, as
well as the service-range container
− alu-conf-system-r13.yang: the OES and port-topology containers.
− alu-conf-svc-vprn-pim-r13.yang: use-lag-port-weight
− alu-conf-sys-sec-r13.yang: auto-crl-retrieval changed to auto-crl-update.
− pre-download-time changed to pre-update-time. Start if the range of seconds in retry-
interval was changed from 0 to 1.
In Release 13.0.R4, these errors have been resolved. The YANG objects that are supported
in Release 13.0.R4 are in the Release 13.0.R4 YANG modules (some objects may have
moved or changed names from their incorrect locations or names in Release 13.0.R1, R2,
or R3). YANG objects that are not supported in Release 13.0.R4 have been removed from
the Release 13.0.R4 modules. [207707-MI]
QoS • Introduced in Release 13.0.R1, the QoS feature “Egress Criteria Classification Directly to a
Policer” makes it possible to classify traffic directly to a policer, independent of the
policer/queue assigned to the traffic’s forwarding class by configuring at SAP egress a
policer in the action statement (action policer policer-id) within an ip-criteria or ipv6-
criteria. The resources consumed by SAPs or subscriber-hosts making use of such a SAP
egress policy are now managed by the system and, once exceeded, will result in a failure of
the action requesting those resources. The tools dump system-resources information has

Resolved Issues
been updated to give the related resource information per line card, namely the total,
allocated and free egress QoS bypass resources. [205006-MA]
• In scenarios where dynamic IOM/IMM/XCM queues were directly parented by a port-
scheduler, it was possible, in very rare cases, for the IOM/IMM/XCM to reboot. This issue
Services General • When an LDP-based SDP was used for SDP-bindings and LDP resolved multiple (ECMP)
paths to the far-end prefix over RSVP LSPs and the next-hops were reachable via different
IOMs, CPM-originated traffic (such as routing protocols, ICMP, or OAM) might not have
egressed out of the spoke-SDP for the following types of services: IES/VPRN spoke-
terminated interfaces, Pipe services, and Routed-VPLS service (Layer-3 control traffic).
• In rare cases, the standby CPM/CFM may have reset if an SNMP SET operation created a
SAP in a VPLS which was operationally up, and then administratively shut down the SAP.
This could happen when configuring VPLS services via SNMP. The workaround was to
delay administratively shutting down the SAP after its creation, such that these actions
were carried out with two distinct SNMP SET operations. This issue has been resolved.
[207099-MI]
• In an oversubscribed multi-chassis redundancy (OMCR) model scenario with large number
of MSAPs per SRRP, the warm-standby node might have failed to send Gratuitous ARPs in
some of the MSAPs associated to an SRRP instance when it became master. This issue has
• When the next-hop for an ICMP destination unreachable message was a tunnel, the ICMP
throttle configuration applied to the outgoing interface might not have resulted in the ICMP
destination unreachable messages getting throttled. This issue has been resolved.
[208928-MI]
Subscriber • When performing a Major ISSU upgrade to releases prior to Release 13.0.R4, multi-chassis
Management synchronization (MCS) remained connected and did not update to accurately reflect newly-
added clients. When performing a Major ISSU to Release 13.0.R4 and higher, all
established MCS connections will now automatically be closed and re-established
immediately after the CPM switchover when the new software becomes active. [194182-
MI]
• On a DHCPv4 relay-enabled interface, DHCPv4 unicast server to client messages (for
example: offer, ack) were not snooped when system was not the first DHCPv4 relay point.
• Subscriber-management-related persistency files may have been reformatted about once
per month on nodes that have their time synchronized via Simple Network Time Protocol
(SNTP). This was not an issue on nodes that used Network Time Protocol (NTP). This
• Using the management routing instance to reach a Diameter peer may have resulted in an
active CPM or CFM reset. This issue has been resolved. [202962-MA]
• The DS-Lite subscriber’s host bits are verified against the configured DS-Lite prefix
length, mandating that the host bits in Lawful Intercept (LI) command are set to zero (0).
This will ensure that a single LI mirror is created for the DS-Lite subscriber, irrespective of
the number of B4 elements (IPv6 addresses) under it. However, in previous releases, when

Resolved Issues
LI for DS-Lite was provisioned via SNMPv3, the host-bits verification was not performed.
Consequently, if an LI with non-zero host bits was configured via SNMPv3 and then saved
in a file, any attempt to restore such LI from the file on the current release would fail due to
non-zero host bits. [206105-MA]
• In rare cases, a PPP link that went down in an MLPPPoX bundle with multiple links,
terminated on a 7750 SR LNS, could have resulted in an LNS MS-ISA/MS-ISA2 reset.
• Prior to Release 13.0.R4, once set, the following attributes could not be changed for a Web
Portal Protocol (WPP) host:
− Framed-IP-Address
− Alc-IPv6-Address
− Framed-IPv6-Prefix
− Delegated-IPv6-Prefix
− Framed-Pool
− Framed-IPV6-Pool
− Slaac-IPV6-Pool
− Alc-Delegated-IPV6-Pool
− Alc-Authentication-Policy-Name
− Alc-Retail-Serv-Id
− Alc-MSAP-Serv-Id
− Alc-MSAP-Policy
− Alc-MSAP-Interface
• SR OS nodes in Release 12.0.R1 or later that had multi-chassis synchronization (MCS)
enabled could have rebooted after months or years of uptime if there was a large amount of
continuous activity by one of the MCS clients like a DHCP server. This issue has been
VPLS • The MAC address of a Routed-VPLS (R-VPLS) routed interface was not protected in the
Routed-VPLS FDB. This issue has been resolved, and now all frames received with that
MAC as a source address will be discarded. [206310-MI]
VPRN/2547 • VPRN traffic arriving on a network interface over a GRE or MPLS tunnel would have been
dropped if the source address in the inner IP header was equal to the network or broadcast
address of the incoming network interface. This issue has been resolved. [203893-MI]
VRRP/SRRP • SR OS does not support IPv4 using VRRP protocol version 3. IPv4 requires VRRP
protocol version 2. If an IPv4 VRRPv3 advertisement was received, a log event was
incorrectly raised. Statistics for invalid version messages should instead have been counted
and displayed using show router vrrp statistics. This issue has been resolved.
[206143-MI]

Resolved Issues
IPsec • Under ca-profile, if using revocation-check crl-optional and no CRL-file was defined,
the IPsec tunnels which expected to match the subject public key info digest (hash) of that
ca-profile’s certificate for cert-profile selection from their configured IPsec cert-profile
might have failed. If no other entries in the cert-profile contained a hash that matched any
of the requested hashes, then the default (first non-blank) entry in the IPsec cert-profile
was selected. This might have been incorrect and caused the tunnel to not come up.
The workaround was to configure a CRL-file in the ca-profile; the CRL-file did not have to
exist. This issue has been resolved. [211521-MA]
• In IPsec static LAN-to-LAN configurations, receiving an IKEv1 message in a Quick Mode
exchange that did not include the ID payloads (IDci and IDcr) might have caused the MS-
ISA to reset. As per RFC 2409, these payloads are expected in a Quick Mode exchange.
Video • A debug configuration for video services saved with the command admin debug-save can
now be successfully executed. [208650-MI]
WLAN-GW • When a “system” IP was not configured under a routing instance, an unwanted GTP packet
received by the instance would have resulted in an unusual error event, “...gtpPathDbNew:
Failed get wlanGw src Addr No interface "system" found”. This issue has been resolved.
[199246-MI]
NAT • RADIUS accounting Request messages to a node acting as RADIUS proxy for large-scale
NAT (LSN) could have caused a memory leak in the “System” pool. After a longer period
of time, this could have resulted in a High-Availability switchover. This issue has been
resolved. [203293, 208709-MA]
• An IP filter with multiple NAT-policies referring to multiple NAT-groups is not supported.
Attempting to apply such a filter onto a SAP generates the following event: “MINOR:
SVCMGR #1228 One of the filter's NAT policies cannot be applied in this vRtr”. Blocking
this invalid configuration was not covered in all cases and could still have been applied; for
example, when an ESM SLA-profile subscriber was created with such IP filter. This issue
• RADIUS accounting Request messages to a node acting as RADIUS Proxy for large-scale
NAT (LSN) could have resulted in unusual error events, such as
“natRadIsaUpdtTask:BB:bbNat GetNextSubIdForIsaUpdt Unexepected action(0)”. This
• Starting with Release 13.0.R4, it is no longer allowed to change the active IOM limit in a
WLAN-GW group containing active subscriber cache entries for subscriber-aware LSN
NAT. [209701-MI]
• In Releases 13.0.R1 to R3, the isa-radius-policy was limited to 512 buffered messages per
MS-ISA card for transmission. In case the AAA server was not replying fast enough to
clear the buffered messages, any new messages that needed to be sent while the buffers
were depleted would have been dropped. This issue has been resolved. [210676-MA]
WLAN-GW and • User-created SAPs that use internal MS-ISA or MS-ISA2 ports are no longer allowed.
NAT Configuration via CLI or SNMP is blocked, as well as via script execution. Note that if any

Resolved Issues
of these SAPs already exist when doing a Minor or Major ISSU, the ISSU will fail.
[187888-MI]
Cflowd • Prior to Release 13.0.R4, a data record containing option values may not have incremented
the flow sequence value. From Release 13.0.R4 onwards, these data records will correctly
cause the sequence number to be incremented each time such options data records are sent.
[196785-MI]
• Enabling Cflowd on FP3-based line cards could, in rare cases, have resulted in resets of
these cards while the following event was being generated: “IO Module : failed, reason:
Reported internal hw error”. The workaround was to disable Cflowd. This issue has been
• Cflowd sample rate was not enforced correctly, and excessive traffic was processed by the
forwarding plane. This might have affected performance when the ingress or egress traffic
was close to the IOM/IMM/XCM maximum capacity. This issue has been resolved.
[210533-MA]
OAM • A Carrier-Serving-Carrier (CSC) PE would not respond to vprn-ping or vprn-trace for a

prefix reachable via the VPRN network interface in a CSC VPRN. This issue has been
• When both EFM-OAM and LACP were enabled on LAG ports and the EFM-OAM state on
one or more LAG ports was repeatedly toggled, in rare cases, a LAG port could have gone
into a state where it would no longer forward traffic. This issue has been resolved.
[202459-MI]
BFD/R-VPLS • Adding or removing a new forwarding complex to an R-VPLS could have caused BFD
packets to no longer egress the R-VPLS interface. This could have been be triggered by the
following actions.
− SAPs were added to/removed from an R-VPLS.
− Ports were added to/removed from network interfaces.
− Member ports were added to/removed from a LAG and that LAG either has the
R-VPLS SAP or network interface.
A workaround was to remove and re-add BFD to the protocol configuration. This issue has
Release 13.0.R3
HW/Platform • Release 13.0.R3 introduced a new firmware version for 7750 SR and 7450 ESS CPM5
cards. The firmware will be upgraded automatically when a node with these cards is
rebooted to a software version Release 13.0.R3 or higher. The new firmware version
resolves an issue with partial packet drop on the CPM management port when that port is
operating at 10 Mbps. [197155, 203590-MI]
• Sending a very specific combination of multicast and unicast high-bandwidth traffic
streams with a traffic generator over an FP3-based IOM could, in very rare cases, have

Resolved Issues
resulted in a lockup of the forwarding plane on that IOM. This issue has been resolved.
[198631-MA]
• If a 10G Ethernet port transitioned from up to down and stayed in the down state for a very
short time (less than 10 ms), it was possible that the operational state of the port would not
toggle although Ethernet alarms were raised. This issue has been resolved. [200605-MI]
• Release 13.0.R3 introduces firmware improvements for p10-10g-sfp, p6-10g-sfp and cx20-
10g-sfp including the support for 1588 port-based timestamping. From Release 13.0.R4
onwards, this upgrade is not mandatory and Soft Reset to releases containing this new
firmware is fully supported; however, a hard reset of the MDA to activate the
improvements is required. [202916-MI]
CLI • Starting a policy configuration change with the begin exclusive command, making some
policy changes, and then letting the begin exclusive time out, could have resulted in a
standby CPM/CFM reset. This issue has been resolved. [203087-MI].
• While the configuration of a policy was constantly being updated for a configuration
change starting with a begin exclusive statement, the standby CPM/CFM may not have
been able to synchronize with the active CPM/CFM after a reset of the standby CPM/CFM.
System • In rare cases, an MS-ISA inserted in an IOM3-XP card might have reset or might have
dropped a very small number of packets over a long period of time; this was not an issue on
MS-ISA2. This issue has been resolved. [200571-MI]
• Configuration of a system>cron>schedule>script-policy that points to both a long script-
policy-name and a long script-policy-owner could have caused truncation and corrupted
names and script-policy associations. The error occured when the total length of the script-
policy-name and script-policy-owner configured in the system>cron>schedule>script-
policy context exceeded 45 characters. This issue has been resolved. [200973-MI]
• The file version check command could fail on large files like support.tim on nodes that
had a relatively low amount of free memory, with this error message: “Checking file
MINOR: CLI Failed to allocate memory for section 0.” This issue has been resolved.
[202059-MI]
• Default log-id 99 or log-id 100, when deleted and created again with different values,
could have resulted in a failure to execute the configuration after a node reboot. The
workaround was to manually edit the saved configuration file and to add two extra lines to
shut down and then delete the log-id in front of that log-id's other configuration statements.
• If default log-id 100 was deleted then recreated with default filter 1001, after a full node
reboot and loading the saved configuration file, filter 1001 was incorrectly no longer
included in log-id 100. This issue has been resolved. [202229-MI]
• The show system alarms command may not have displayed older existing alarms until a
new event or alarm took place after a CPM/CFM switchover. This issue has been resolved.
[202755-MI]
• In rare cases, taking a tech-support file, while an IOM/IMM/XCM is continuously
rebooting, could have resulted in a High-Availability CPM switchover. This issue has been

Resolved Issues
LAG • With a scaled number of LAGs configured on a node, it could have taken longer to display
the output of show lag detail or show lag description. This issue has been resolved.
[189138-MI]
Routing Policies • The combination of a long prefix-list name and an IPv6 prefix may have been rejected by
CLI. The workaround was to modify the prefix-list name to a shorter one. This issue has
IP/RTM • In rare cases, using ICMP-tunneling in conjunction with ECMP routes might have affected
protocols and subsequently caused a High-Availability switchover. The preventive
workaround was to remove icmp-tunneling from the configuration. This issue has been
DHCP • DHCPv4 subscriber hosts with IPv4 address and subnet obtained from AAA or Local User
Database (DHCP proxy server) could not be instantiated on a group-interface where also
DHCP relay-proxy with siaddr-override was enabled. This issue has been resolved.
[200765-MA]
• When DHCP relay-proxy siaddr-override was enabled, a DHCP INFORM message to a
remote DHCP server would be dropped on the DHCP Relay in a Wholesale/Retail
scenario. This issue has been resolved. [202208-MI]
• When a DHCP Relay was configured with relay-proxy release-update-src-ip and
gi-address ip-address src-ip-addr, a locally-generated unicast DHCP release message
would incorrectly use the client IP address as the source IP address instead of the gi-
address. This issue has been resolved. [203125-MI]
• An SR OS local DHCPv6 server now accepts multiple Vendor-Specific Information (VSI)
options (option code 17) within Relay-Forward messages. Prior to Release 13.0.R4, such
messages were dropped by the local DHCPv6 server. [205458-MA]
OSPF • OPSF Link State Update authentication failure error events could have been generated
sporadically in networks with multiple OSPF areas if authentication was turned on at the
OSPF interface level. This was the case when flapping links would result in a large number
of summary LSAs to be flooded through one or more OSPF areas. This issue did not result
in any service or OSPF performance impact, and the probability for the errors to occur was
increased if the OSPF lsa-arrival timer was configured to a value of zero (0) on all nodes
in the network. This issue has been resolved. [199972-MI]
• OSPF may have incorrectly advertised a leaked route when two nodes were leaking the
same prefix from BGP-VPN, while ignore-dn-bit was configured. This issue has been
BGP • On highly-scaled BGP nodes with a large number of BGP neighbors and many sent and
received BGP update messages, typical for BGP route reflectors in a large network, in very
rare cases, either the active or standby CPM/CFM could have reset. On nodes equipped
with two CPMs/CFMs, neither of these resets would have resulted in any service impact
because of control plane high-availability. This was only an issue on systems with a multi-
core CPM/CFM and has now been resolved. [177586-MA]

Resolved Issues
• A VPRN that had both enable-bgp-vpn-backup and export-inactive-bgp configured and

that received the same routes from a BGP peer as well as from a BGP-VPN peer, with the
routes from the BGP-VPN being the best routes, could have resulted in continuous route
updates in the VPRN route table and continuous high CPU usage. This issue only happened
if all PE VPRN instances used the same Route Distinguisher (RD). The workaround was to
disable either the enable-bgp-vpn-backup or the export-inactive-bgp configuration
statements. This issue has been resolved. [200543-MA]
• In certain scenarios where a local route exactly overlapped with an aggregate route, BGP
could have incorrectly selected the aggregate route as the best route. To mitigate the issue
and have the best route always advertise via a BGP export policy, both policy entries from
protocol direct and from protocol aggregate were required. This issue has been resolved.
[203120-MI]
• When BGP prefixes were learned over a static ESM subscriber host for which the next hop
(static-host) was resolved via a default-host configuration on the group interface SAP,
those BGP prefixes would be installed in the route-table but would be blackholed in the
FIB, which resulted in all traffic to that BGP-learned destination being dropped. This issue
MPLS/RSVP • Bringing an XMA card operationally down or changing the IMPM bandwidth policy on a
Forwarding Path (FP) on a 7950 XRS would have caused RSVP/mLDP P2MP traffic that
was ingressing on the other XMA card, present in the same XCM card, to be dropped. The
following actions would have caused this issue:
− executing the command clear mda
− physically removing an XMA card without first performing an administrative
shutdown
− making an XMA card go operationally down through Intelligent Power Management
− a change of the bandwidth-policy on one FP when the bandwidth-policy is initially
the same on both FPs
The issue was resolved as soon as the XMA card became operationally up or after both
FPs’ bandwidth policies had been changed. To prevent this issue, IMPM had to be enabled
on both FPs of the XCM card, with a different bandwidth-policy (the policy contents
could be the same but the policy names needed to be different) configured on each FP. If
both FPs were configured with the same bandwidth-policy (including the “default”
bandwidth-policy), applying the preventive workaround required a subsequent change of
bandwidth-policy on both FPs. This issue has been resolved. [206741-MI]
IP Multicast • IP multicast traffic could have stopped being forwarded on some egress LAG ports for
some PIM multicast groups after one LAG port flapped rapidly or multiple LAG ports
flapped at the same time, if both of the following conditions were met:
− the outgoing-interface LAG ports were distributed over multiple forwarding
complexes
− the PIM option lag-usage-optimization was enabled
The workaround was to disable this PIM option. This issue has been resolved.
[205321-MA]

Resolved Issues
Filter Policies • When GRE-encapsulated traffic matched a VPRN network ingress filter entry having a
filter log configured, the log output decoded the outer GRE header and not the inner IP
header used in match. This issue has been resolved. [198980-MI]
• VPRN network ingress filter policies, in the
config>service>vprn>network>ingress>filter context, are no longer restricted to chassis
mode D and are now available for network chassis mode D. Network chassis mode D
means access interfaces can be on older IOM types but all network interfaces are on FP2-
based or newer cards. [200526-MI]
Subscriber • Sending a RADIUS COA disconnect that is first executed on a PPP-DHCPv6 host for a
Management subscriber having multiple hosts would incorrectly not delete all hosts of this subscriber. If
the COA disconnect was first executed on a different host type of the same subscriber, then
all hosts and the subscriber were correctly removed. This issue has been resolved.
[204403-MI]
• On a VPRN VRRP master interface with Subscriber Host-Connectivity Verification
(SHCV) enabled, configured parameter source interface was never applied and source
vrrp was incorrectly used instead. This was not an issue on an IES VRRP master interface.
IPsec • The following CLI commands might have incorrectly displayed the output for more than
one object if the desired object name was the initial part of the of the name of other objects:
− show ipsec cert-profile name
− show ipsec cert-profile name association
− show ipsec trust-anchor-profile name association
− show ipsec ts-list name
− show ipsec ts-list name association
For example giving “CERT” as object name will show the information for “CERT”,
“CERT1” and “CERT2”. This issue has been resolved. [206904-MI]
BFD • The last sent/received timestamps were not updated in the show router bfd session
command output for BFD sessions of type cpm-np. This issue has been resolved.
[204759-MI]
OAM • An OAM vxlan-ping test launched with a “test-id 0” was rejected with the error “MINOR:
OAM #1002 Test configuration is incomplete”. This issue has been resolved. [201481-MI]
• For the ETH-CFM CCM Interface Status TLV, under very specific conditions, the Interface
Status stored on the local MEP did not represent the value of the Interface Status TLV
received in the ETH-CC message from the remote MEP. When a remote MEP immediately
sent back-to-back state changes for this value, off-cycle from the CCM interval, it was
possible that the receiving MEP would improperly report the Interface Status of the peer
unless the MEP’s operational state was toggled (shutdown/no shutdown). This issue has
• The traceroute command could have failed to process the ICMP response from certain
third party routers if that ICMP response packet included a length attribute for the “original
datagram” field as specified in RFC 4884. This issue has been resolved. [206539-MI]

Resolved Issues
Release 13.0.R2
Synchronization • When all of the following conditions were present, the BITS Output would have continued
to output 2048 kHz signal instead of squelching the signal.
− BITS reference type was set to G.703 T12 (2048 kHz) signal format.
− BITS Out source was set to “line-reference”.
− BITS Output was enabled.
− There was no valid reference available (not configured or administratively down or
the reference had failed).
OpenFlow • An H-OFS flow entry programming would fail for a dot1q SAP match and for an action
that translated to forward sap, where the SAP was a QinQ SAP. This issue has been
• Flow Table entry counters for flow priority 0 entry were not reliable when OpenFlow was
embedded in filters with a filter ID value above 16000. This issue has been resolved.
[202088-MA]
NETCONF • Content match nodes in an <get-config> request (section 6.2.5 of RFC 6241) are only
supported for key leafs in SR OS. A request containing a non-key content match node now
returns an error as expected instead of a corrupted reply. [202582-MI]
Management • The IPv6 loopback address 0::1 is now correctly blocked in log snmp-trap-group trap-
target configuration and in snmp src-access-list src-host configuration. [201542-MI]
DHCP • Removal of a DHCPv6 lease-state triggered by lease timeout could have incorrectly
resulted in “subMgmtIpoe lost sync with peer” to be logged on a standby MCS node.
Although it could have taken up to 60 seconds before the next “subMgmtIpoe back in sync
with peer” event was logged, the MCS database was not actually out of sync, and it was a
false alarm. This issue has been resolved. [198763-MI]
IS-IS • During graceful restart, the loss of a BFD adjacency would tear down an IS-IS adjacency
when include-bfd-tlv was configured on the IS-IS interface. The IS-IS adjacency would be
restored when graceful restart had completed. This issue has been resolved. [185250-MA]
• Using rollback to revert changes in the prefix-sid-range as configured in IS-IS may have
resulted in the use of the wrong SID labels despite the fact that the new SID range was
populated in the IS-IS database. This issue has been resolved. [201093-MA]
BGP • A BGP export policy entry may have incorrectly matched untagged local routes when a
match criterion based on a specific tag value being configured. This issue has been

Resolved Issues
BGP-EVPN • When receiving BGP-EVPN routes with VXLAN encapsulation, the MPLS label field is
no longer treated as a label but as a 24-bit VNI (VXLAN Network Identifier).
[200915-MA]
LDP • A change to one or more LDP session fec-type-capability options from enable to disable
or vice-versa on both LDP LSR peers, followed by a CPM/CFM High-Availability
switchover on one LSR, might have resulted in the standby CPM/CFM state where that
LSR would not be updated with the new negotiated FEC type capability state. This was the
case when the State Advertisement Control (SAC) capability TLV was received from the
peer immediately following the local configuration change. The issue could have been
avoided by changing the fec-type-capability options only on one of the LDP LSR peers.
If the LSR got into the above state, the user could apply one of the following two methods
to correct the FEC type capability state.
− Toggle the impacted fec-type-capability options on the LSR peer only two times to
get it back to the desired value. This was the preferred option as it kept the LDP
session.
− Clear the LDP session.
PIM • On PIM interfaces, no Hello packet with holdtime 0 would be sent to the original active
PIM neighbor when modifying the link-local-address. As a result, the remote PIM
neighbor would have two entries with the old and new link-local-address until the old one
timed out. To prevent this, Alcatel-Lucent recommended shutting down the PIM interface
before changing the link-local-address. Shutting down the PIM interface would trigger a
Hello packet with holdtime 0 for the original active PIM neighbor, allowing the peer to
remove its PIM neighbor entry. This issue has been resolved. [200752-MA]
QoS • In Release 13.0.R1, the commands configure qos sap-egress policy-id dynamic-policer
range and configure qos sap-ingress policy-id dynamic-policer range were incorrectly
made available, but were not supported. These commands are now correctly disabled in
Release 13.0.R2. [201701-MI]
Filter Policies • Rollback of an IPv4/IPv6 filter that changes its scope to or from scope system failed if the
filter contained the same entry IDs before and after the change. This issue has been
Services General • A system rollback may have failed when static IPv6 hosts were configured on group-
interface SAPs. This issue has been resolved. [200715-MI]
Subscriber • The configure subscriber-mgmt diameter-application-policy policy-id nasreq user-

Management name-operation command was not supported for PPP. This issue has been resolved.
[200872-MI]
• The length of the description field of the system persistency configuration of the Python-
policy cache could not exceed 32 characters. This issue has been resolved. [201407-MA]

Resolved Issues
• The remote-id, which can be included in a NASREQ AAR message, was not correct. The
remote-id in the calling-station-id avp was correct and could have been used as workaround
to retrieve the correct remote-id. This issue has been resolved. [201617-MI]
• A python-policy name string that exceeded 31 characters might have caused system
instability in certain circumstances. In the SR OS 13.0.R1 Release Notes, this issue was
incorrectly noted as “exceeding 32 characters”. This issue has been resolved. [201660-MA]
IPsec • The hop limit of IPv6 IKE packets has changed from 255 to 64 to be consistent with other
IPsec packet types. [201127-MI]
• The show router route-table ipv6 summary command incorrectly displayed the IPsec
routes count as zero (0), even though IPsec routes were present. This issue has been
• An IPv6-over-IPv6 IKEv2 remote-access tunnel that used EAP authentication could not be
established. This issue has been resolved. [202465-MA]
Mirroring/Lawful • The lawful interception routable LI shim header session-id and intercept-id were not
Intercept correctly inserted into the copied packets for traffic that was intercepted on egress using an
IPv6 filter entry as the li-source criteria (such as an IPv6 filter applied to the egress side of
a SAP, or a subscriber). This issue affected all FP3-based cards on the 7750 SR, 7450 ESS
and 7950 XRS platforms. This issue has been resolved. [201392-MI]
• When a packet was lawfully intercepted (LI) by a mirror destination that was configured
with routable encapsulation (config>mirror>mirror-dest>encap>layer-3-encap), and the
LI gateway destination IP address was reachable (best path) via an L3 spoke-SDP-
terminated interface (spoke interface), then the packet would not be sent correctly over that
spoke interface. The packet would instead be sent as a native IP packet (without any GRE
or MPLS SDP encapsulation that a spoke interface normally uses) from the network
interface onto which the spoke interface was currently bound. Note that the network
interface out of which the packet was sent may not have been the best (or even a valid) path
to reach the LI gateway for a native IP packet (if excluding spoke interfaces from available
paths). This issue has been resolved. [201452-MA]
WLAN-GW • In WLAN-GW, if the GGSN sent a Delete PDP Context Request, the corresponding
response was always sent to destination UDP port 2123, even if the original port was
something else. This issue did not occur with GTPv2 and has been resolved. [198403-MI]
• MPLS tunneled GTP-U traffic from GGSN/PGW could have resulted in a corrupted UDP
source port and GTP-U TEID. This issue has been resolved. [202486-MA]
NAT • On scaled configurations with many static port forward entries present, it is possible that
after a node reboot, some MS-ISA cards will require more than one hour to become active.
[200170-MA]
• Optimizations have been implemented to handle more RADIUS Accounting Requests by a
node acting as RADIUS proxy for subscriber-aware NAT. [200176-MA]
• If a value for NAT outside MTU was configured, the configuration may have been ignored
after a node reboot, allowing larger packets to be forwarded without fragmentation. This

Resolved Issues
• In very rare cases, fragmented NAT traffic could have triggered an MS-ISA/MS-ISA2
reset. This issue has been resolved. [202382-MA]
Application • Sending a RADIUS COA or Diameter RAR with the same app-profile VSA that was
Assurance applied and without ASO VSAs did not remove the previous ASO override policy as
expected. The output of show commands would indicate that the ASO overrides were
removed, but the policy associated with those overrides was still being applied. This issue
Release 13.0.R1
All resolved issues in Releases 12.0.R2 to 12.0.R8 also apply to Release 13.0.R1. Refer to the
SR OS 12.0.R8 Release Notes for issues resolved in Releases 12.0.R2 through 12.0.R8.
HW/Platform • The enhancement that was implemented in older releases for IOM3-XPs, IMMs and XCMs
to recover automatically from memory errors on the switch fabric interface was not
working correctly for all types of memory errors, and certain errors could still have resulted
in the drop of multicast traffic across the switch fabric. This issue has been resolved.
[181634-MA]
• The system now recovers gracefully from certain transient errors in the switch fabric.
[184482-MA]
• After a High-Availability switchover on a 7950 XRS, removing the CCM associated with
the previously active CPM may have caused some chassis information (Base MAC address
and Hardware Data) to be erased from the system memory. A subsequent High-Availability
switchover would reload the missing information into memory. This issue has been
• The show chassis CLI routines no longer show Chassis 2 information in a 7950 XRS-20
system until one of the following conditions is met:
− the system is actually configured and operating in a 7950 XRS-40 chassis topology
mode
− any APEQs, line cards or SFMs in Chassis 2 have been explicitly provisioned
[195377-MI]
• On the 7750 SR-a4 and SR-a8, using the management port at 10M speeds could have
resulted in significant packet loss. A workaround was to ensure that the management port is
operating at 100M speeds. This issue has been resolved. [197154-MA]
System • When using the file vi command to edit files, there is a 1024 character limit on the amount
of text to be pasted correctly. Exceeding that limit would have caused the pasted content to
be overwritten. This issue has been resolved. [126371-MI]
• On an iom2-20g, IPv4 and IPv6 transit traffic is now counted in the MIB objects
vRtrIfTxBytes/vRtrIfTxPkts of VRtrIfStatsExtEntry. [192987-MI]
• After trying to enter candidate edit exclusive mode while someone else was already in
candidate edit mode, “tmnxSysCandidateCfgExclusiveUsr” would incorrectly contain the
user name of the user that tried to enter exclusive mode, and show system candidate

Resolved Issues
would incorrectly indicate the candidate config was exclusive locked. This had no
functional impact on the operation of the candidate config. This issue has been resolved.
[200363-MI]
NTP • Within the NTP time recovery process, on rare occasions, the leap second would be
disarmed momentarily before UTC midnight, resulting in no time step. Similarly, on rare
occasions, the leap second would be re-armed after the time step, causing a second time
step. In both cases, the NTP recovered time would be in error by up to one (1) second and
would then slowly realign to the NTP server time. This issue has been resolved.
[200687-MI]
MC-LAG • A High-Availability switchover on the standby MC-LAG (without LACP) peer may have
caused the standby ports to toggle operationally. This issue has been resolved. [193578-MI]
SNMP • Custom (user created) SNMP views no longer contain unsupported OIDs. An SNMP walk
Infrastructure on a custom view no longer causes the active CPM/CFM to reset. It is no longer necessary
to add the same default excluded OIDs as are contained in the iso view into custom views
[97589-MI].
Routing • A static-route whose prefix was more specific than the interface's subnet would get
activated when the interface came up. When the interface went down, the static-route
would not get deactivated. This issue has been resolved. [186424-MI]
IP/RTM • A traceroute of an IPv4 prefix in Carrier-Serving-Carrier (CSC) VPRN would time out at
both the ingress and egress CSC PE routers when the latter had the icmp-tunneling option
enabled. This issue has been resolved. [186141-MI]
Routing Policies • Accumulated IGP (AIGP) metric attribute modifications in a policy used for next-hop-
resolution were not supported and should not have been configured. Configuring such
policies could have resulted in system instability. This issue has been resolved.
[196796-MA]
IS-IS • The system no longer sends an LSP with zero (0) lifetime if it receives a PSNP packet for
an LSP that is no longer present in the IS-IS database. [178018-MI]
• When an IS-IS instance was set up with Multi-Topology (MT) ipv6-multicast, and a
route-nh-template configured with protection-type link was added to an IS-IS interface,
after a reboot of the active CPM/CFM, the calculated LFA would be correct, but its metric
would be incorrect. This issue has been resolved. [188681-MI]
• After a configuration rollback that involved an IS-IS router-id configuration change, IS-IS
is now restarted to make the original router ID active again. [189859-MI]
• When IS-IS packet debug was enabled, packets may not have appeared in the same order in
the debug output as the order in which they were processed if the processing time between
these packets was very short. This issue has been resolved. [189998-MI]

Resolved Issues
BGP • A remote BGP-VPN route tunneled via RSVP could have its age updated incorrectly but
without service impact when the RSVP backup path changed. This issue has been resolved.
[187299-MI]
• In some conditions where the interface state changes rapidly, static-routes could fail to
monitor reachability to next-hops correctly with the validate-nexthop option. When this
occurred, the static routes state could be recovered by deleting and recreating them. This
• On the 7750 SR-a4/a8, show system connections detail did not show queue statistics for
some TCP connections if the number of BGP neighbors configured was more than 1000.
• An aggregate route in a VPRN will no longer be incorrectly advertised via MP-BGP if the
same prefix as the aggregate prefix was present in the VPRN route table prior to the
aggregate command being applied. [198170-MI]
LDP • The configured value (enabled/disabled) of the prefer-tunnel-in-tunnel option was

inverted in the output of show router ldp parameters command. This issue has been
IP Multicast and • When creating an IPv6-only interface, an “Interface interface-name is not operational”
MVPN event may have appeared in the event logs even though the interface was up and running.
• PIM groups are now correctly resolved when using a BGP confederation with P2MP
provider-tunnels. [191479-MA]
• In certain scenarios where the (S,G) state of a multicast group in an intersite-shared MVPN
had timed out, enabling intersite-shared kat-type5-adv-withdraw later would not cause
the source-PE to withdraw the source-AD BGP NLRI for that (S,G) entry. This issue has
Filter Policies • The CLI display for source and destination MAC filter match criteria has been enhanced to
properly display an all-zeros MAC address or an undefined MAC address match criterion.
[199142-MI]
Services General • A redirect-policy with a ping test in the context of a VPRN may not have worked as
expected. The system may have incorrectly sent ICMP packets to the base instance instead
of the VPRN instance. This issue has been resolved. [83771-MI]
• When a multi-chassis ring (MC-ring) was configured with fast BFD timers and the port on
one side of the MC-ring was shut down, the other side may have remained in the connected
state instead of going to the broken state. This was only an issue after an administrative
port shutdown, not after the port went down for other reasons (such as a fiber cut).
[195727-MI]
• For a spoke-SDP or mesh-SDP of vc-type VLAN, the configuration of force-vlan-vc-
forwarding was incorrectly allowed, and should have been blocked. This configuration is
no longer allowed. [197491-MA]

Resolved Issues
Subscriber • Configuring ignore-mclt-on-takeover as a DHCP failover option may have resulted in

Management PPPoE database corruption if multi-chassis sync lost synchronization for a period greater
than the partner-down-delay. A workaround was to clear all PPPoE sessions with MAC
addresses for which the conflict was reported. This issue has been resolved. [185920-MA]
• With a large number of Python cache entries (above 50K per Python policy), removing the
MCS peer from the Python policy could have resulted in the MCS peer going out-of-sync.
Other MCS clients such as DHCP-server can be temporarily affected but recover after a
few seconds. Alcatel-Lucent recommends removing the MCS peer configuration from a
Python policy when a large number of Python cache entries were stored. This issue has
• Only a NA prefix length of 64 is supported for ESM. It is no longer possible to change this
value via Python. [197114-MI]
• Python cache is now supported on the 7750 SR-a4/a8 platform. [198251-MA]
• No RADIUS accounting interim-update message was generated for subscriber hosts with
an SLA-profile name that is exactly 32 characters long. RADIUS accounting start or stop
messages were not affected by this issue. This issue has been resolved. [198855-MI].
VPLS • A Routed-VPLS service does not support Multicast-VLAN-Registration (MVR). When

allow-ip-int-bind is already enabled in the VPLS service, configuring mvr from-vpls or
mvr to-sap below the SAP is correctly prevented. However, first configuring SAP mvr
from-vpls or mvr to-sap and afterwards enabling allow-ip-int-bind was not blocked and
could have resulted in a failure to execute the configuration file after a node reboot. This
• When restrict-protected-src alarm-only was configured with the auto-learn-mac-
protect command, the moving MAC was learned on the other SAP. This issue has been
WLAN-GW • Local User Database (LUDB) DHCPv6 option match criteria are now supported for
RADIUS proxy. [187291-MI]
• When comparing the Called-Station-Id part of a RADIUS message to the previously stored
RADIUS proxy data, comparison could have failed because of a different MAC separator.
From now on, the Called-Station-Id is parsed regardless of the MAC separator and is not
case-sensitive; however, the SSID name must be an exact match. [197933-MI]
• If after a WLAN-GW IOM reset where the lightweight UE was previously allocated, a new
RADIUS-proxy-cache lookup done within 10 seconds of the IOM reset for this same UE
could have resulted in system instability. [200081-MA]
• In very rare cases, having enabled debug wlan-gw could have resulted in packet re-
ordering or MS-ISA reset. This issue has been resolved. [200404-MI]
• The header of RADIUS accounting messages could have been corrupted when making use
of distributed RADIUS-proxy. This issue has been resolved. [201180-MA]
PBB • IGMP reports are usually unicast to a querier that is either manually configured or
automatically discovered. In an SPB network running SPF forwarding tree for unicast and
ST forwarding tree for multicast with different routing paths, IGMP report frames were

Resolved Issues
dropped due to ingress check when the paths became divergent. This issue has been
NAT • RADIUS messages could have incorrectly had the same Acct-Multi-Session-Id upon
allocating and de-allocating multiple different port blocks of the same subscriber, although
a NAT accounting policy with multi-session-id was applied. This issue has been resolved.
[200389-MI]
Application • For HTTP proxy traffic, the host field in the HTTP header was used for expression-
Assurance matching instead of the host in the fully-qualified URL, as described in section 5.2 of
RFC 2616. This issue has been resolved. [198163-MI]
Cflowd • If the system’s Ethernet management port flaps, the system may not have been able to send
Cflowd records to the collector and the following error will be logged “Cflowd failed to
send packet to collector <dst.ip> – Reason: tmnxCflowdUDPSendFailure”. The user could
manually set the Cflowd source address under config>system>security>source address
application as a temporary workaround. This issue has been resolved. [116245-MI]
OAM • lsp-trace of a BGP labeled route with the DDMAP TLV option would fail at the egress
ASBR if multi-hop eBGP was used between ASBR nodes. This issue has been resolved.
[166209-MI]
• When ECMP is enabled, lsp-trace and ldp-treetrace may have failed with incorrect
rc=5(DSMappingMismatched) on the 7950 XRS-40. A workaround was to run lsp-trace
with min-ttl to resume from failed location or run lsp-ping with incrementing TTL values.
There was no workaround for ldp-treetrace. This issue has been resolved. [190943-MA]

Known Issues
Known Issues
Following are specific technical issues that exist in Release 13.0.R10 of SR OS. See also Known
Limitations, as some known issues may have been moved to that section.
Notes:
• Known issues added in this release are marked with an asterisk. (*)
• Issues marked as MI have a minor impact and will not disturb network traffic.
• Issues marked as MA may have a major impact on the network and may disturb traffic.
• Issues marked as CR are critical and will have a significant amount of impact on the network.
HW/Platform • The optics modules details displayed in the output of the show port detail CLI command
may be displayed in hexadecimal notation instead of the normal decimal notation if the
optics modules parameters were incorrectly programmed to include non-printable ASCII
characters. The specific value is appended with “(hex)” to indicate such an occurrence.
[84012-MI]
• Back-to-back runts may not be counted correctly under port statistics on 100GE ports.
Also, some runts may be counted as fragments. [129447-MI]
• The system marks any IOMs/IMMs/XCMs as “failed” if they have rebooted due to an
internal failure more than five (5) times in a period shorter than or equal to 25 minutes.
Marking the cards as “failed” and generating log messages is currently also done for the
standby CPM. This is incorrect since the standby CPM cannot be prevented from
rebooting. [149975-MI]
• On some CPMs on the 7750 SR-12e platform, the management-port traffic LED blinking
may cause the Power LEDs to also blink. [176890-MI]
* When the 7950 XRS is operating as an XRS-40 and some ports are to be configured for
synchronous Ethernet, then the BITS ports of the Extension chassis must be cabled to a
synchronous source. If there is no need for synchronous Ethernet ports, then there is no
need to cable the BITS ports; however, currently, a benign critical alarm will be raised
against the BITS ports on the extension chassis if they are not cabled.
There are two available workarounds:
− set the event-control for tmnxEqSyncIfTimingHoldover and
tmnxEqSyncIfTimingHoldoverClear to suppress
− cable the BITS ports on the extension chassis using one of the two configurations
shown in the installation guide, and configure the sync-if-timing bits output to
source internal-clock. [192096-MI]
• A reboot or extraction of a newly-inserted line card while the firmware is being
automatically updated can result in a CPM/CFM High-Availability switchover.
[207888-MI]
• FCS errors on received frames on a 100G Ethernet port may incorrectly cause the “ingress
FCS errors” alarm to be reported against the ingress forwarding complex of the line card.
This alarm should only be reported for FCS errors due to an internal defect. [228977-MI]
* Ingress FCS errors on Ethernet ports are incorrectly counted as Threshold Drops on the
port. [229141-MA]

Known Issues
* After a Soft Reset on the p1-100g-tun-b card, the Maximum Rx Per-Channel Power field in
Coherent Optical Port Statistics incorrectly displays 0.0 if the Maximum was a negative
value before the reset. [231536-MI]
* In very rare cases, a switch fabric capacity alarm may be raised for a short time after a new
card is being added to a chassis. [233911-MI]
Synchronization • For IMMs and MDAs that support IEEE 1588 port-based timestamping, after an ISSU, the
CPM may expect the port to execute port-level timestamping of the PTP frames, although
the IMM or MDA is not running the up-to-date firmware that supports this feature. This
may result in corrupted correction fields in the PTP messages. This only impacts PTP ports
(Ethernet encapsulation) and not PTP peers (IP encapsulation). To resolve this issue, the
firmware should be upgraded using the clear card or clear mda command. The firmware
version can be verified with the show command of the assembly (for example, show mda
1/1 detail). [228493-MI]
CLI • Special characters (“\s”, “\d”, “\w”) do not work with pipe/match functions. [100089-MI]
• File operations using TFTP will fail if the hostname contains the “-” character. The
workaround is to use FTP or the IP address instead of the hostname. [222805-MI]
• Removing or adding certain candidate configuration can trigger false CLI warnings like
"Deleting non-existing node ..." or "Referencing non-existing object ... ", while the
candidate configuration change is valid and applied correctly. [226091-MI]
System • If no new events are logged after the retention period, a file will not be created on the
compact flash. A CLI show of the log-id will then give a false error: “MINOR: CLI Could
not access”. [94600-MI]
• Copying a file to a TFTP destination sometimes prompts for a confirmation to overwrite
the destination file on the TFTP server, even if that file does not exist. [120649-MI]
• A CLI rollback revert operation that requires the change of certain attributes on channels
that are associated with a channelized SONET/SDH ports may shut down the base port in
instances where the shutdown is not required. [121080-MI]
• CPU-protection policies are not supported at the IES/VPRN tunnel-interface SAP-
level/context but in some cases, it is incorrectly shown as configurable. Note that a CPU-
protection policy (if desired) should be applied at the tunnel-interface level instead of at the
tunnel-interface SAP-level. [133148-MI]
• Packet spraying efficiency drops when the number of BGP next-hops to a prefix is greater
than eight (8) and where the number of resolving links for some BGP next-hops is greater
than (8) as well. [198707-MA]
• If a Time-of-Day (ToD) time-range is deleted without previously deleting all of the
configuration parameters within it, the tmnxPeriodicTimeRangeParmsTable may be left
with a stale entry. When the system is in this state, if the standby CPM/CFM resets, it will
be unable to synchronize with the active CPM/CFM. [211211-MI]
NETCONF • An explicitly defined “delete” operation on a key leaf, regardless of the existence of the
key leaf, acts as a “merge” operation. [212204-MI]

Known Issues
ATM • When a non-terminating ATM SAP (atm-vpc or N:1 connection-profile) is implemented

on a multi-chassis-APS (MC-APS) group, and both MC-APS member ports fail, the SAP
will source ATM ETE-AIS cells onto the pseudowire, in addition to setting the
lacIngressFault and lacEgressFault pseudowire status bits. The opposite SAP, at the other
end of the pseudowire, will send out the AIS cells, while also generating its own in
response to the PW status change. This results in the opposite SAP sending AIS cells at a
rate of two (2) per second instead of one (1). There are no false alarms or other ill effects,
and both AIS cell flows stop when service is restored. [147334-MI]
MLPPP • If an MLPPP bundle with more than one (1) link has magic-number configured and all
links are looped back, a link may not become active when it stops being in a looped-back
state. To recover from this and to allow the link to become active, shut down the bundle and
toggle the magic-number attribute. [143509-MI]
APS • Individual APS channel group members may be reported as down while the APS port
status is operationally up. This is strictly a display issue. [89341-MI]
• If a CLI rollback operation must remove or alter the working bundle associated with a
BPGrp, then it will also delete and rebuild any APS port associated with that BPGrp.
[121024-MI]
• A CLI rollback operation that requires the removal of member links from a multilink
bundle or BPGrp will shut down the associated bundle or BPGrp during the course of its
operations, even if one or more member links still remain throughout the course of the
rollback. [121066-MI]
• If all APS ports are active on either the working or protect router with a highly-scaled MC-
APS configuration including MLPPP BPGrps and that router reboots, some PPP links may
suffer PPP keepalive failures during the APS switchover process. In that case, the link will
bounce and renegotiation will occur. [156523-MI]
ATM IMA • When an IMA group is deleted while the group still contains IMA member links, some of
the member links may show erroneous DS1 and DS0 ingress statistics after the deletion.
[151573-MI]
SNMP • The system may not correctly count the number of failed SNMPv3 authentication attempts
Infrastructure in the event-control log. [64537-MI]
• SNMP replay events may not function properly for replay functionality with multiple trap-
targets pointing to the same address (even if they belong to different trap-groups/logs). This
issue does not affect replay functionality with only one trap-target per trap-receiver
address. [69819-MI]
• The system may not return a lexicographically higher OID than the requested OID in an
SNMP GET-NEXT operation when incorrect values are used. This behavior is seen in the
tcpConnectionTable table. [80594-MI]
• After 497 days, any “Last Change” counter on the system will wrap around due to a 32-bit
timestamp limitation. The “Last Oper Chg” value in the output of the show router
interface command is one example of such counter, but there are numerous other cases
where this limitation applies. [83801-MI]

Known Issues
• A system that does not have a system IP address or a management IP address configured
may not be able to generate SNMP traps. [98479-MI]
• SNMP traps are not forwarded when overwriting or modifying existing trap-target in both
the base and VPRN context. [177129-MI]
DHCP • An IP address that is released and immediately granted again by the master local-dhcp-
server may, in rare cases, result in a false positive alarm on the standby failover local-
dhcp-server: “BNDUPD message could not be processed for DHCP lease * – reason:
hostConflict”. [177704-MI]
IS-IS • When used in combination with ECMP, the show router isis lfa-coverage command may
provide incorrect results. [142527-MI]
• When overload max-metric is configured under IS-IS, internal routes are still reachable
through the overloaded node, but with a maximum metric value. The behavior is different
for external routes; they are no longer redistributed into IS-IS when overload max-metric
is configured. [172440-MI]
• Debugging IS-IS packet detail does not show an incoming packet that causes the router to
update the database and purge an LSP. However, debugging IS-IS packet does show this
packet. In Release 13.0.R4, the Purge Originator Identification (POI) TLV can be enabled
with poi-tlv-enable to help identify the system ID of the router that generated the purge.
[180227-MI]
• If only one multi-instance (MI-IS-IS) instance is configured with iid-tlv-enable, IS-IS
incorrectly accepts LSPs from other instances. This issue does not occur if multiple
instances are configured. [227683-MI]
* After 497 days, when the system up-time wraps around due to the standard RFC 1213
MIB-II 32-bit limit, the time stamps displayed by the show router isis spf-log commands
may be incorrect. [232019-MI]
BGP • Changing the BGP router-id value in a base or VPRN configuration will immediately
cause a flap of all BGP neighbors that are part of that instance. [121246-MI]
• When performing a VPRN configuration change followed by a High-Availability
switchover on the root node of a RSVP or mLDP PMSI, the intra-area BGP-AD routes for
the PMSI are not installed in the root node. The workaround is to clear the BGP neighbor.
[134851-MI]
• A PE node may not advertise a non-best CE route in MP-BGP, even if export-inactive-bgp
is enabled, when there are other protocols exchanging the same prefixes as BGP on the CE
side. [177879-MI]
• The CLI show command for MVPN BGP routes does not correctly filter on originator-ip,
source-ip, and group-ip addresses. This is the case when filtering with the default
addresses in MVPN-IPv4 and with any MVPN-IPv6 addresses when no type is given.
[185058-MI]
• When a BGP neighbor has advertise-label enabled and the BGP adjacency comes up
without the remote side advertising the MP-BGP capability, BGP routes can be sent out
with invalid labels to this neighbor and other BGP neighbors with a similar configuration in
the same routing instance. [229551-MI]

Known Issues
* A BGP peer with enable-peer-tracking and the next-hop of the BGP neighbor resolved
via a recursive lookup can have the session flapped because of changes in the import
policy. [232537-MI]
* If only the prefix-length-range is changed inside a prefix-list context to a more specific
value, and this prefix-list is part of an import BGP policy, the old policy result is retained.
[232686-MI]
* The error-handling update-fault-tolerance command should be used in nodes running
Releases 13.0.R10 and earlier when interoperating with nodes that support VXLAN IPv6
transport. [233504-MA]
BGP-EVPN • When an EVPN route is withdrawn because of a parsing error, a withdrawn log-event is
generated but an additional log-event to indicate the reason of the error is not always
generated. In some error cases related to an EVPN mpunreach attribute, there is no log-
event generated when this attribute is ignored. [184549-MI]
• The output of the show router bgp routes evpn evpn-type hunt command cannot be
filtered using the bgp-tunnel-encap or ext:Mac extended communities. [184643-MI]
• In a scenario with EVPN all-active multi-homing, a PE part of the Ethernet Segment (ES)
may learn a MAC “M1” in the FDB associated to a local SAP in the ES, but as type evpn
(this is possible if “M1” was learned on a peer ES PE and subsequently advertised in
EVPN). In this situation, new frames received on the local ES SAP with MAC SA = M1
will not trigger the relearning of M1 as type “Learned”, as would be expected. This may
generate some unnecessary extra flooding from remote PEs if the peer ES PE withdraws
M1. [208989-MA]
• According to RFC 7432, when more than two PEs are part of a single-active Ethernet
Segment (ES), a remote PE detecting the unavailability of the DF PE is expected to flush
all of the MACs associated to the ES and flood any unicast traffic destined to that ES.
However, in the current release and in this scenario, the remote PE will spray the unicast
traffic among all remaining PEs in the ES without flushing the MAC addresses associated
to the ES. [209329-MI]
• The use of the same import route-target for multiple VPLS services is not currently
recommended. [205726-MI]
• In EVPN services, Multicast CFM PDUs generated from UP MEPs are sent to EVPN-
MPLS/VXLAN destinations even though the VPLS service is shut down. [210995-MA]
• CPM/CFM parsing of control frames (IGMP-snooping and proxy-ARP/ND) received from
VXLAN or EVPN-MPLS destinations only works on Ethernet ports. [211856-MA]
MPLS/RSVP • A non-CSPF LSP path whose next-hop is over an unnumbered interface will not come up if
traffic engineering is disabled in IS-IS or OSPF. In addition, RSVP needs the router ID of
the next-hop to look up an existing neighbor or to create a new neighbor before sending out
the PATH message to the local and remote borrowed interface address. This information is
looked up in the Traffic Engineering (TE) database. [146593-MI]
• For LSPs over unnumbered interfaces, routed messages such as RESV, RESVTEAR and
PATHERROR are destined to the remote-router ID. A successful RTM lookup for the
packet destination is necessary to send the message. If the IGP is shut down, then RTM
lookup will fail, and the message may get dropped. [153707-MI]

Known Issues
• When using an unnumbered IP interface as a Traffic Engineering (TE) link for the
signaling of RSVP P2P LSP and P2MP LSP, it is required that all nodes in the network
have their router-id set to the system interface. [153791-MI]
• Under certain conditions and topology, there is a chance that a one-to-one detour
originating from a PLR will be incorrectly merged by a detour merge point such that the
detour terminates back onto the same PLR. [157528-MI]
• With unnumbered RSVP interfaces, the RESV message from an LSR to its upstream
neighbor can use a different interface than the PATH message. If the authentication
parameters of the links used by the PATH and RESV messages are different, either they use
a different key, or authentication is disabled in one of the links; the upstream LSR detects
the authentication mismatch and discards the RESV message. The LSP will not come up.
The reason is that the RESV packet is actually routed to the upstream neighbor. This is not
an issue with numbered interface since the upstream neighbor uses the local interface
address in the Previous Hop (PHOP) object in the PATH message and thus, the RESV is
always routed via the link used by the PATH message and representing the same subnet.
With unnumbered interface, the PHOP object uses a loopback address of the upstream
neighbor that corresponds to the borrowed IP address of the unnumbered interface used by
the PATH message. Thus, routing back to this loopback address can use a different link
than the one used by the PATH message which does not necessarily follow the shortest path
due to CSPF. It can also be due to asymmetric routing over the link, and this issue will
occur even if the PATH message used the shortest path.
The workaround is to configure the same authentication parameters on all RSVP interfaces,
numbered or unnumbered, where a RSVP packet may be sent or received. [160106-MI]
LDP • The value of LDP graceful restart state is always “capable”, even when the remote node
does not signal that it is capable of performing graceful restart. [79430-MI]
• LDP Path-MTU Discovery is not reducing the Path MTU correctly in presence of IGP-
shortcuts if the MTU of the tunnel is less than the MTU of the interface at the ingress LER.
[140723-MI]
• Modifying the system-interface IP address may cause LDP to keep the old IP address in the
LIB/LFIB as a local prefix binding. To remove this binding, the LDP’s administrative state
must be toggled. [149930-MI]
• When transitioning from a peerTemplate-driven T-LDP session to a manually-configured
T-LDP session with local-lsr-id enabled, the session will flap. [165590, 165888-MI]
• As part of the Auto T-LDP feature, peerTemplates are saved in the configuration file based
on the order of creation. When a rollback save is performed and subsequently the user
deletes or recreates the same peerTemplate, thus altering the template creation time, the
rollback restore operation is not capable of reverting the template configuration based on
the initial creation order at the time of the rollback save. [166160-MI]
* Using vc-switching command in combination with a far-end node having a system IP
address or remote IP address as 0.0.0.0 results in a wrong switching TLV, causing standby
CPM/CFM to reboot [230996-MI]
IGMP • A MIB walk or GET-NEXT of the vRtrPimNgGrpSrcHostEntryTable can result in a loop

when more than one entry is populated. [154205-MI]

Known Issues
PIM • In rare cases, interfaces may have the same IPv6 link-local address, which is used as the
primary interface address for IPv6 PIM. If the interfaces in the RP tree and shortest-path
tree have the same IPv6 link-local address, then the router will be unable to send RTP-
prune messages. [152125-MI]
• lag-usage-optimization is supported only when per-flow, MID-based hashing is enabled
on a LAG and when no queue or SAP optimizations are enabled on the LAG. The
configuration is not blocked when the condition is not met, and using lag-usage-
optimization may lead to disruptions in multicast traffic. [180482-MI]
• In some cases, the “Curr Fwding Rate” in the output of show router x pim group detail
may incorrectly show a value after traffic for this multicast group has stopped.
[202141-MI]
• Shutting down and deleting an interface rapidly (for example, using a script) may cause
some multicast traffic not to be forwarded to other interfaces that are part of the Outgoing
Interface lists (OIF lists) containing the deleted interface. To prevent this from happening,
the interface should be deleted at least five (5) seconds after it becomes operationally
down. To recover from the incorrect state, the affected multicast groups can be toggled
with the clear router pim database command. [203559-MA].
QoS • When modifying the in-remark and out-remark DSCP values for SAP QoS policies via
SNMP, the new values will not be applied to traffic. A workaround is to modify these
values with CLI. [228141-MI]
Filter Policies • When removing a filter that has a default-action deny from a SAP or interface, a very
small number of packets may be dropped. [92351-MI]
• If the ingress or egress ACL/QoS filter entry resources on any line card are close to full
utilization (above 90% of capacity) for a given filter type, then the performance of some
configuration updates to these filters may be degraded, especially during large
configuration changes when using long filter match-lists, or large embedded filters.
Configuration update performance degradation does not impact data-path performance of
the line card. [161389-MI]
• Service Function IP (SF-IP) in IP filters with ESI action should be configured to a valid
unicast IP address. Invalid SF-IPs should be removed prior to upgrade. ISSU cannot be
done with a configuration containing invalid SF-IPs, and execution of config files with
invalid SF-IPs will not be successful. [212698-MI]
Services General • If ETH-CFM is configured on a SAP in a BGP-EVPN VPLS where cfm-mac-

advertisement is enabled, and the MAC used for the MEP/MIP is the SAP’s physical port
MAC, when the card goes offline, the EVPN will not withdraw the MAC route
corresponding to the MEP/MIP MAC. As a workaround, a specific MAC address for ETH-
CFM in the BGP-EVPN VPLS service SAPs can be configured. [213818-MI]
• When a SAP/spoke-SDP is associated with a single-active Ethernet Segment (ES) and the
router has not yet received Auto-Discovery (AD) per-ES routes, the ES may incorrectly
behave as all-active mode until the es-activation-timer expires. The issue is only present
in non-PBB-EVPN services. [230567-MA]

Known Issues
Subscriber • When a RADIUS CoA message triggers the change of both subscriber-profile and SLA-
Management profile, a RADIUS Accounting-Stop message is generated for the subscriber. The
Accounting-Stop message does not include the old subscriber-profile name, but the new
subscriber-profile name from the CoA message. [94758-MI]
• In case a QinQ capture-SAP has a port inner Ethernet type value configured different from
the default value “0x8100”, and authentication-policy uses pap-chap as access method, the
PPPoE PADO message is incorrectly sent out of the MSAP with the default inner Ethernet-
type 0x8100. This is not an issue in case the capture-SAP is dot1q-tagged or the
authentication-policy used is different from pap-chap. [137800-MI]
• A DHCP ACK returned by a VPLS DHCP proxy will be incorrectly tagged and not reach
the DHCP client in case the VPLS SAP where the client connects to is not a service
delimiting tag or the outer customer tag. [147457-MA]
• ECMP load-balancing to identical RADIUS Framed-Routes/Framed-IPv6-Routes with
different next-hop is not supported in the following Wholesale/Retail scenario:
− A combination of ECMP Framed-Routes/Framed-IPv6-Routes belonging to hosts on
a subscriber interface with private-retail-subnets enabled and hosts on a subscriber
interface without private-retail-subnets enabled.
In this scenario, a part of the ECMP load-balanced traffic will be dropped. [167136-MA]
• SCTP source or destination port ranges match in IPv4 and IPv6 ingress or egress subscriber
management credit control filters is not supported. [199371-MI]
• Gx Usage Monitoring is not supported in a dual-homed configuration. The error reporting
via Error Message AVP to indicate this not-supported behavior is missing for Gx PCC-
Rules. [211556-MI]
• For RADIUS-based credit control, when credit is exhausted or depleted, the system will
normally send a RADIUS authentication message; however, the RADIUS message is
incorrectly not generated in case the authentication-policy is applied via a local-user-db.
[222924-MI]
• In a dual-homed setup with the local DHCP server as master but the local subscriber
interface operationally down, a renew DHCP Ack message unicast from server to client is
incorrectly dropped. Broadcast DHCP rebind or new clients setup via remote DHCP Relay
are still successful. [230337-MI]
* If a subscriber host is not responding to Subscriber Host-Connectivity Verification (SHCV)
ARP-requests for some time (for example, because of a CPE reboot) and SHCV started its
last period waiting for an ARP-reply, a DHCPv4/v6 renew will not reset the SHCV timers,
and thus, SHCV can incorrectly remove the DHCPv4/v6 lease-state immediately after it
was renewed. [231777-MI]
VPLS • The per-service hashing feature will not work for egress VPLS management IP traffic in a
VPLS service. [91377-MI]
• CPM- or CFM-originated packets sent on a VPLS management interface are mapped and
treated as NC forwarding-class regardless of their DSCP value. [102765-MI]
• In a VPLS using an I-PMSI and a spoke-SDP of vc-type VLAN, when L2PT or BPDU-
translation is enabled on the service and STP BPDUs are received over P2MP leaf, they are
incorrectly dropped as “Bad BPDUs”. [134168-MI]
* If a VPLS is configured as a dynamic service via a Python script and the VPLS
configuration includes BGP with route targets, the route-target configuration is missing

Known Issues
from the info include-dynamic command output although these route targets are
operationally present and, hence, there is no service impact. [232082-MI]
Routed VPLS • Traffic is incorrectly dropped if all of the following conditions are met.
− A Routed-VPLS (R-VPLS) service is configured to allow the forwarding of IPv4
multicast traffic from the VPLS to the IP side of the service.
− Multicast traffic enters a SAP or spoke-SDP in the VPLS side of the service which
should be forwarded to a different SAP or spoke SDP in that VPLS service based on
IGMP snooping state.
− The shortest path to the source is across the R-VPLS IP interface. [209900-MA]
PBB • ISID-level shaping on a B-SAP is not performed for traffic entering a Routed I-VPLS
service which is forwarded over a B-SAP configured with encap-defined-qos. In this case,
the traffic uses the normal SAP queues on the B-SAP rather than those associated with the
encap-defined-qos. [217774-MA]
Video • In some cases, clearing the video interface statistics can cause it to incorrectly show a
higher “Tx FCC Replies” count than the “Rx FCC Requests” count. [182951-MI]
• In rare cases when using a multicast-service, adding a new primary MS-ISA to an existing
video group may cause some FCC/RET requests and multicast traffic to not be forwarded
to all MS-ISAs in the group. The recovery action is to re-provision the affected MS-ISAs.
[189479-MA]
WLAN-GW • If subscriber-management persistency is enabled, WiFi UE mobility between access points

(APs) can fail in some cases, displaying the following drop reason in DHCP debug traces:
“Problem: There is currently another transaction active for this lease state”. The work-
around is to disable subscriber-management persistency. [195056-MI]
* When a packet’s IPv4 header checksum is incorrect, it is currently dropped with root cause
“no host” instead of “ipv4 hdr chksum”. [233088-MI]
* The User-Name attribute is currently not learned from the RADIUS Access-Request
message in case of distributed RADIUS proxy. If the User-Name is also not returned in the
RADIUS Access-Accept message, the User-Name value can be empty in RADIUS
Accounting messages. [234162-MI]
NAT • Dynamic ports are always reserved, even if only deterministic port blocks have been
reserved via configuration. [195357-MI]
• Deconfiguring a deterministic prefix with several thousands of deterministic maps may
cause the MS-ISA to reboot. [208698-MA]
• With active-active NAT group redundancy configured, during full reboot or after no
shutdown of the NAT-group, traffic may be loaded on the first MS-ISA’s coming up and
revert to a stable, balanced load over all MS-ISAs in the group shortly thereafter.
[210575-MA]

Known Issues
• L2-Aware NAT policies can currently be configured to allow block-limit greater than 1.
This is not supported. L2-Aware NAT policy can only have default block-limit of 1. Even
if a higher block-limit is configured, it will not be in effect. [211949-MI]
• On scaled configurations with many static port forward entries present, some ISA cards
may take a very long time to become active after a node reboot. [215131-MA]
• Performing a nat-group or nat-pool shutdown with scaled L2-Aware configuration and
many subscribers present might cause the standby CPM to reset. The subscribers must first
be cleared before shutdown. [222915-MA]
MSDP • Logs may incorrectly show an MSDP peer transitioning from established to a lower state
when the remote peer has not been configured to accept MSDP sessions and has a higher IP
address. This does not cause any service impact. [161762-MI]
TMS • Issuing a clear router router-id interface tms-itf-name statistics command while a clear
mda is being processed results in invalid TMS-interface statistics. When this error occurs,
issuing the command again when the MS-ISA (as ISA-TMS) “TMS Health Information”
status is up will clean the statistics properly. [124650-MI]
Application • Under unexpected fragmented GREv1 traffic conditions, benign trace errors may be seen.
Assurance [212589-MI]
• With traffic locally routing between two (2) DPI-enabled endpoints, traffic destined to a
DPI-enabled IPsec Private SAP will not be diverted to AA resulting in no DPI analysis
being performed in that direction. [213919-MA]
• If a Local URL List is configured and in use, and no HTTP host string is collected from an
HTTP or TLS session, a benign "dpiUrlListLookup" trace message may be displayed.
[230667-MI]
BFD • Upon reset of an ASAP MDA, IS-IS may not re-register as a BFD client on multilink
bundles. [62885-MI]
OAM • oam vprn-trace packets incorrectly time out when sent to ASBRs in an inter-AS
configuration. [59395-MI]
• In scaled scenarios, SAA ETH-CFM tests configured to run in continuous mode may
experience some probe packet loss. [90784-MI]
• When SAA ETH-CFM continuous tests are configured and CPM or CFM redundant
system is configured for redundancy synchronize boot-environment, the SAA ETH-
CFM tests may experience some probe packet loss upon switchover during the Boot
Environment Synchronization stage. [92500-MI]
• A reply to a p2mp-lsp-ping of an mLDP FEC will fail at the leaf LSR if the latter is
enabled with the multicast upstream FRR feature (mcast-upstream-frr option) and has
activated LFA next-hop towards the backup upstream LSR. [162937-MI]
• ETH-CFM: When a port member in a LAG changes from a non-operational to operational
state, a sub-second CCM-enabled QinQ Tunnel Facility LAG MEP (LAG + VLAN)
associated with that LAG will experience a timeout condition which will cause attached

Known Issues
services to propagate fault. It is suggested that these Facility MEPs use a minimum CCM
interval timer of one (1) second. [200980-MI]
• Sub-second CCM MEPs may not transition to a defect state for possibly six (6) seconds
upon IOM reset on the 7750 SR-a4/a8 platforms. [209430-MI]

Change History for Release 13.0 Release Notes

The following table lists significant documentation changes to the SR OS 13.0 Software Release
Notes.
Table 16. Change History
Part number Date of Issue Reason for Issue and Changes to Documentation
3HE098980010 June 2016 Tenth 13.0 Release Notes
TQZZA_01
3HE098980009 May 2016 Ninth 13.0 Release Notes
TQZZA_01
3HE098980008 March 2016 Eighth 13.0 Release Notes
TQZZA_01 • Divided previous hardware table “IOM, IMM, ISM, and
MDA Cards Supported in the 7450 ESS in Mixed-Mode”
into two tables: “IOM, IMM, and ISM Cards Supported
in the 7450 ESS in Mixed Mode” and “MDAs, ISAs, and
VSMs Supported in the 7450 ESS in Mixed Mode”.
3HE098980007 January 2016 Seventh 13.0 Release Notes, Edition 2.
TQZZA_02 • Update to enhancement 199185.
• Added resolved issue 222322-MA.
3HE098980007 January 2016 Seventh 13.0 Release Notes.
TQZZA_01
3HE098980006 November 2015 Sixth 13.0 Release Notes.
TQZZA_01
• Known limitations and known issues added in the
current release are marked with an asterisk.
3HE098980005 September 2015 Fifth 13.0 Release Notes.
TQZZA_01
• “Enhancements” section moved directly after “New
Features” section.
• “Limited Support Features” section renamed as
“Limited Support Features and Enhancements”.
3HE098980004 July 2015 Fourth 13.0 Release Notes.
TQZZA_01
• “About this Document” section added.
• Units updated for consistency:
• Gb (gigabits)
• Gb/s (gigabits per second—now used instead of Gbps)
• Gbytes (gigabytes)
• Gbytes/s (gigabytes per second)
3HE098980003 May 2015 Third 13.0 Release Notes.
TQZZA_01 • Unsupported features are listed by type, using tables;
previously, they were listed by platform using lists.
• The heading “TPSDA” (Triple-Play Service Delivery
Architecture) is replaced with “Subscriber Management”.

Table 16. Change History (Continued)
Part number Date of Issue Reason for Issue and Changes to Documentation
3HE098980002 April 2015 Second 13.0 Release Notes.
TQZZA_01 Change to how features, enhancements, commands, and
issues that were added or resolved in a release prior to the cur-
rent release, but which were not documented in the Release
Notes until the current release, are documented:
• In the 12.0 Release Notes, these items are documented in
the section for the current release, and are noted by using
the phrase “actually”; for example: “This issue was
actually resolved in Release 12.0.R5.”
• In the 13.0 Release Notes, these items are listed under the
release in which they were added or resolved. A table
pointing to these newly-documented features,
enhancements, or issues is included in the New Features,
Enhancements, Changed or Deprecated Commands, or
Resolved Issues section of the current release.
3HE098980001 February 2015 First 13.0 Release Notes.
TQZZA_01 Added new sections since 12.0 Release Notes:
• List of Tables
• Limited Support Features
• Deprecated Features
• Changed or Deprecated Commands
• Change History
• Technical Support

Technical Support
Technical Support
If you purchased a service agreement for your router and related products from a
distributor or authorized reseller, contact the technical support staff for that distributor
or reseller for assistance.
If you purchased an Alcatel-Lucent service agreement, contact technical assistance at:
http://www.alcatel-lucent.com/support
Report documentation errors, omissions, and comments to:
Documentation.feedback@alcatel-lucent.com
Include document name, version, part number and pages affected.
Document Part Number: 3HE09898 0010 TQZZA 01

No portion of this document may be reproduced in any form or means without prior written permission from Alcatel-Lucent.
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. Arbor Networks, the Arbor Networks
logo, Peakflow, Pravail, ATLAS and ArbOS are trademarks of Arbor Networks, Inc. All other trademarks are the property of their
respective owners.
The information presented is subject to change without notice.
Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2016 Alcatel-Lucent. All rights reserved.
3HE09898 0010 TQZZA 01

Technical Support

SR OS 13.0.R10 Software Release Notes PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SR OS 13.0.R10 Software Release Notes PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Alcatel-Lucent

Service Router | Release 13.0.R10

3HE09898 0010 TQZZA Edition 01

About this Document....................................................................................................................... 1

Release 13.0.R10 Documentation Set ............................................................................................ 2

New Features ................................................................................................................................. 26

Limited Support Features and Enhancements ......................................................................... 106

Unsupported Features ................................................................................................................ 107

Deprecated Features ................................................................................................................... 113

SR OS 13.0.R10 Software Release Notes

Release 13.0.R7 .......................................................................................................................................113

Changed or Deprecated Commands.......................................................................................... 115

Usage Notes ................................................................................................................................. 135

Software Upgrade Procedures ................................................................................................... 151

Known Limitations....................................................................................................................... 178

Known Issues............................................................................................................................... 276

Change History for Release 13.0 Release Notes ...................................................................... 287

SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes

About this Document

SR OS 13.0.R10 Software Release Notes 1

Release 13.0.R10 Documentation Set

Table 1. Release 13.0.R10 Documentation Set

Document title Platform Part number

2 SR OS 13.0.R10 Software Release Notes

Table 1. Release 13.0.R10 Documentation Set (Continued)

Document title Platform Part number

SR OS 13.0.R10 Software Release Notes 3

Release 13.0.R10 Supported Hardware

Supported Chassis Configurations

Table 2. Supported 7950 XRS Chassis Configurations

Table 3. Supported 7750 SR and 7450 ESS Chassis

4 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 5

6 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 7

8 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 9

10 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 11

12 SR OS 13.0.R10 Software Release Notes

1. Supported with SFM3/4/5.

SR OS 13.0.R10 Software Release Notes 13

14 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 15

Supported Adapters (XMA, MDA, ISA, CMA, VSM)

Table 8. XMAs and C-XMAs Supported in 7950 XRS

16 SR OS 13.0.R10 Software Release Notes

Table 8. XMAs and C-XMAs Supported in 7950 XRS (Continued)

Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR

SR OS 13.0.R10 Software Release Notes 17

Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)

18 SR OS 13.0.R10 Software Release Notes

Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)

SR OS 13.0.R10 Software Release Notes 19

Table 9. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)

1. See Usage Notes for specifics.

20 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 21

22 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 23

24 SR OS 13.0.R10 Software Release Notes

SR OS 13.0.R10 Software Release Notes 25