SR OS 11.0.R20 Software Release Notes

SR OS 11.0.
R20
DEC-02-2015
SR OS 11.0.R20
SOFTWARE RELEASE NOTES
These release notes are for Release 11.0.R20 of the SR OS software for the 7950 XRS, 7750 SR,
7450 ESS and 7710 SR routers.
Release Notes Organization

The following are the major topics covered in these Release Notes:
Alcatel-Lucent
Release 11.0.R20 Documentation Set on page 4
Release 11.0.R20 Supported Hardware on page 5
New Features in 11.0.R20 on page 20
*93-0446-20 V11.0.R20*
93-0446-20 V11.0.R20

-
Hardware on page 45
System on page 50
Services on page 53
TPSDA on page 56
Quality of Service on page 73
Routing on page 75
MPLS on page 82
Application Assurance Services on page 87
OAM on page 88
Unsupported Features in 7950 XRS on page 89
Unsupported Features in 7750 SR-12e on page 90
Unsupported Features in 7750 SR-c4 and SR-c12 on page 91
Unsupported Features in 7450 ESS on page 91
Unsupported Features in 7710 SR on page 92
Enhancements on page 93
-
Release 11.0.R20 on page 93
SR OS 11.0.R20 Software Release Notes
Usage Notes on page 139
Software Upgrade Procedures on page 156

-
Software Upgrade Notes on page 156
AA Signatures Upgrade Procedure on page 162
ISSU Upgrade Procedure on page 166
Standard Software Upgrade Procedure on page 180
Known Limitations on page 183
Resolved Issues on page 222
Resolved in 11.0.R20 on page 222
Known Issues on page 306
Release 11.0.R20 Documentation Set
Release 11.0.R20 Documentation Set

The SR OS Release 11.0.R20 documentation set consists of Release Notes and the 7950 XRS,
7750 SR, 7450 ESS and 7710 SR manuals. The components of the Release 11.0.R20 documentation set are the following:
SR OS 11.0.R20 Software Release Notes (Document Part Number: 93-0446-20)
11.0 AA Protocols and Applications for the 7450 ESS and 7750 SR (3HE 10506 AAAA
TQZZA)
Advanced Configuration Guide 4.0 (93-0267-04)
7750 SR OS Basic System Configuration Guide 11.0 (93-0070-10)
7750 SR OS System Management Guide 11.0 (93-0071-10)
7750 SR OS Interface Configuration Guide 11.0 (93-0072-10)
7750 SR OS Router Configuration Guide 11.0 (93-0073-10)
7750 SR OS Routing Protocols Guide 11.0 (93-0074-10)
7750 SR OS MPLS Guide 11.0 (93-0075-10)
7750 SR OS OAM and Diagnostics Guide 11.0 (93-0181-07)
7750 SR OS Services Guide 11.0 (93-0076-10)
7750 SR OS Quality of Service Guide 11.0 (93-0077-10)
7750 SR OS Triple Play Guide 11.0 (93-0098-09)
7750 SR OS Multi-Service Integrated Services Adapter Guide 11.0 (93-0262-04)
7750 SR OS RADIUS Attributes Reference Guide 11.0 (93-0472-01)
7450 ESS OS Basic System Configuration Guide 11.0 (93-0100-10)
7450 ESS OS System Management Configuration Guide 11.0 (93-0101-10)
7450 ESS OS Interface Configuration Guide 11.0 (93-0102-10)
7450 ESS OS Routing Configuration Guide 11.0 (93-0103-10)
7450 ESS OS Routing Protocols Guide 11.0 (93-0104-10)
7450 ESS OS Quality of Service Guide 11.0 (93-0105-10)
7450 ESS OS MPLS Guide 11.0 (93-0106-10)
7450 ESS OS Services Guide 11.0 (93-0107-10)
7450 ESS OS Triple Play Guide 11.0 (93-0099-10)
7450 ESS OS OAM and Diagnostics Guide 11.0 (93-0183-07)
7710 Service Router OS Basic System Configuration Guide 11.0 (93-0097-09)
7710 Service Router OS System Management Guide 11.0 (93-0080-09)
7710 Service Router OS Interface Configuration Guide 11.0 (93-0081-09)
7710 Service Router OS Router Configuration Guide 11.0 (93-0082-09)
7710 Service Router OS Routing Protocol Guide 11.0 (93-0083-09)
7710 Service Router OS MPLS Guide 11.0 (93-0084-09)
7710 Service Router OS OAM and Diagnostics Guide 11.0 (93-0182-07)
7710 Service Router OS Services Guide 11.0 (93-0085-09)
7710 Service Router OS Quality of Service Guide 11.0 (93-0086-09)
Release 11.0.R20 Supported Hardware
7710 Service Router OS Triple Play Guide 11.0 (93-0143-08)
7950 SR OS Basic System Configuration Guide 11.0 (93-0400-02)
7950 SR OS System Management Guide 11.0 (93-0401-02)
7950 SR OS Interface Configuration Guide 11.0 (93-0402-02)
7950 SR OS Router Configuration Guide 11.0 (93-0403-02)
7950 SR OS Routing Protocols Guide 11.0 (93-0404-02)
7950 SR OS MPLS Guide 11.0 (93-0405-02)
7950 SR OS OAM and Diagnostics Guide 11.0 (93-0408-02)
7950 SR OS Services Guide 11.0 (93-0406-02)
7950 SR OS Quality of Service Guide 11.0 (93-0407-02)

The following tables summarize the hardware supported in SR OS Release 11.0.R20. New
hardware supported since SR OS Release 10.0.R1 is printed in bold. .
TABLE 1. 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
TABLE 2. Supported 7750 SR, 7450 ESS and 7710 SR Chassis

Alcatel-Lucent
Model #
7750 SR-1
Description
7750 SR-1 chassis (AC and DC)
7750 SR-7
7750 SR-12
7750 SR-12e
7750 SR-12e chassis
7750 SR-c4
7750 SR-c4 chassis (AC and DC)
7750 SR-c12
7450 ESS-1
7450 ESS-1 chassis (AC and DC)
7450 ESS-6
7450 ESS-6v
7450 ESS-6v chassis (vertical ESS-6)
7450 ESS-7
7450 ESS-12
7710 SR-c12
7710 SR-c4
The following tables summarize the Switch Fabric/Control Processor Modules (SF/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) and Input/Output Modules (IOMs) and Integrated Media Modules (IMMs) supported
in SR OS Release 11.0.R20.
TABLE 3. 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)
TABLE 4. SFM, CFM, MCM, CCM, IOM and IMM Line Cards Supported in 7750
SR
Alcatel-Lucent
Part #
Description
3HE00018AA
7750 SR 400 Gbps Switch Fabric/CPU Module (SF/CPM) (SR-7, SR-12)
3HE00019AA
7750 SR 200 Gbps Switch Fabric/CPU Module (SF/CPM) (SR-7 only)
3HE00019AB
7750 SR 200 Gbps Switch Fabric/CPU Module (SF/CPM) (SR-7 only)
3HE00020AB
7750 SR 20G Input Output Module (IOM) Baseboard (iom-20g-b)
3HE01170AA
7750 SR 400G SF/CPM2 (SR-7, SR-12)
3HE01171AA
7750 SR 200G SF/CPM2 (SR-7 only)
3HE01473AA
7750 SR 20G Input Output Module (IOM2) Baseboard (iom2-20g)
3HE03607AA
7750 SR-c12 CFM-XP
3HE03608AA
7750 SR-c12 MCM-XP
3HE03617AA
7750 SR-12 SF/CPM3 (SR-7, SR-12)
3HE03619AA
7750 SR IOM3-XPa (iom3-xp)
3HE03622AA
7750 SR 4-port 10GE fixed port IOM (IMM)
3HE03623AA
3HE03624AA
7750 SR 48-port GE fixed port IOMa (IMM)
3HE03625AA
7750 SR 48-port GE copper port IOMa (IMM)
3HE04164AA
7750 SR-7 SF/CPM3 (SR-7 only)
3HE04580AA
7750 SR-c12 CCM-XP
3HE04741AA
7750 SR 5-port 10GE fixed port IOMa (IMM)
3HE04743AAAB
7x50 12-port 10G Ethernet SFP+ IMM - L3HQ
SR (Continued)
Alcatel-Lucent
Part #
Description
3HE05053AAAB
7x50 1-port 100G Ethernet CFP IMM- L3HQ
3HE05055AA
7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMMa

- L3HQ
3HE05553AA
3HE05553BA
7x50 12-port 10G Ethernet SFP+ IMM - L3BQ
3HE05813AA

- L2HQ
3HE05813BA

- L3BQ
3HE05814AA
7x50 1-port 100G Ethernet CFP IMM - L2HQ
3HE05814BA
7x50 1-port 100G Ethernet CFP IMM - L3BQ
3HE05895AA
7x50 48-port GE fixed port IOM (IMM)a - L2HQ
3HE05895BA
7x50 48-port GE fixed port IOM (IMM)a - L3BQ
3HE05896AA
7x50 48-port GE copper port IOM (IMM)a - L2HQ
3HE05896BA
7x50 48-port GE copper port IOM (IMM)a - L3BQ
3HE05898AA
7x50 5-port 10GE fixed port IOM (IMM)a - L2HQ
3HE05898BA
7x50 5-port 10GE fixed port IOM (IMM)a - L3BQ
3HE05899AA
7x50 8-port 10GE fixed port IOM (IMM) - L2HQ
3HE05899BA
7x50 8-port 10GE fixed port IOM (IMM) - L3BQ
3HE05948AA
7750 SR-12 SF/CPM4 (SR-12)
3HE05949AA
7750 SR-7 SF/CPM4 (SR-7)
3HE06318AA
7750 Multicore-CPU IOM3-XPa
3HE06320AA
7x50 3-port 40GE QSFP IMM- L3HQ
3HE06326AA
7x50 48-port GE Multicore-CPU SFP IMMa - L3HQ
3HE06326BA
7x50 48-port GE Multicore-CPU SFP IMMa - L3BQ
3HE06326CA
7x50 48-port GE Multicore-CPU SFP IMMa - L2HQ
3HE06428AA
7x50 48-port GE fixed port IOM (IMM)a - L3HQ
3HE06429AA
7x50 48-port GE copper port IOM (IMM)a - L3HQ
3HE06430AA
7x50 5-port 10GE fixed port IOM (IMM)a - L3HQ
3HE06431AA
3HE06721AA
7x50 3-port 40GE QSFP IMM - L2HQ
3HE06721BA
7x50 3-port 40GE QSFP IMM - L3BQ
3HE06798AA
7750 1-port 40GE DWDM Tunable IMMa - L3HQ
3HE06798BA
7750 1-port 40GE DWDM Tunable IMMa - L3BQ
SR (Continued)
Alcatel-Lucent
Part #
Description
3HE06798CA
7750 1-port 40GE DWDM Tunable IMMa - L2HQ
3HE07158AA
7x50 12-port 10GE FP3 SFP+ IMMa - L3HQ
3HE07158BA
7x50 12-port 10GE FP3 SFP+ IMMa - L3BQ
3HE07158CA
3HE07159AA
7x50 1-port 100GE FP3 CFP IMMa - L3HQ
3HE07159BA
7x50 1-port 100GE FP3 CFP IMMa - L3BQ
3HE07159CA
3HE07166AA
7750 SR-12e SF/CPM4-12e (SR-12e only)
3HE07167AA
7750 SR-12e Mini-SFM4-12e (SR-12e only)
3HE07303AA
3HE07303BA
7x50 2-port 100GE FP3 CFP IMMa - L3BQ
3HE07303CA
3HE07304AA
7x50 6-port 40GE FP3 QSFP IMMa - L3HQ
3HE07304BA
7x50 6-port 40GE FP3 QSFP IMMa - L3BQ
3HE07304CA
7x50 6-port 40GE FP3 QSFP IMMa - L2HQ
3HE07305AA
3HE07305BA
7x50 20-port 10GE FP3 SFP+ IMMa - L3BQ
3HE07305CA
3HE08019AA
7x50 1-port 100GE DWDM Tunable FP3 IMMa - L3HQ
3HE08019BA
7x50 1-port 100GE DWDM Tunable FP3 IMMa - L3BQ
3HE08019CA
7x50 1-port 100GE DWDM Tunable FP3 IMMa - L2HQ
3HE08020AA
7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMMa - L3HQ
3HE08020BA
7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMMa - L3BQ
3HE08020CA
7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMMa - L2HQ
3HE08173AA
7750 SR-c12 CFM-XP-B
3HE08174AA
7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMMa - L3HQ
3HE08174BA
7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMMa - L3BQ
3HE08174CA
7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMMa - L2HQ
3HE08175AA
7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMMa - L3HQ
3HE08175BA
7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMMa - L3BQ
3HE08175CA
7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMMa - L2HQ
SR (Continued)
Alcatel-Lucent
Part #
Description
3HE08421AA
7750 SR SF/CPM5-12e (SR-12e only)
3HE08422AA
7750 SR Mini-SFM5-12e (SR-12e only)
3HE08423AA
7750 SR CPM5
3HE08426AA
7750 SR IOM3-XP-Ca
3HE08428AA
7750 SR SFM5-12
3HE08429AA
7750 SR SFM5-7
3HE09260AA
7750 SR SFM5-12 + CPM5
3HE09261AA
7750 SR SFM5-7 + CPM5
3HE09279AA
7x50 48-port GE MultiCore SFP IMM - L3HQa
3HE09279BA
7x50 48-port GE MultiCore SFP IMM - L3BQa
3HE09279CA
7x50 48-port GE MultiCore SFP IMM - L2HQa
a. Supported on 7750 SR-12e.
TABLE 5. SFM, IOM and IMM Line Cards Supported in 7450 ESS
Alcatel-Lucent
Part #
Description
3HE00229AB
7450 ESS IOM 20G LINE CARD (iom-20g-b)
3HE00316AA
7450 ESS SF/CPM 200G (ESS-7 only)
3HE01172AA
7450 ESS SF/CPM2 200G (ESS-7 only)
3HE02032AA
7450 ESS SF/CPM2 400G (ESS-7, ESS-12 only)
3HE02297AA
7450 ESS SF/CPM2 80G (ESS-6 and ESS-6v only)
3HE03618AA
7450 ESS-12 SF/CPM3 (ESS-7, ESS-12 only)
3HE03619AA
7750 SR IOM3-XP (iom3-xp)
3HE03620AA
7450 ESS IOM3-XP (iom3-xp)
3HE03622AA
3HE03623AA
3HE03624AA
7750 SR 48-port GE fixed port IOM (IMM)
3HE03625AA
7750 SR 48-port GE copper port IOM (IMM)
3HE04166AA
7450 ESS-7 SF/CPM3 (ESS-7 only)
3HE04741AA
3HE04743AAAB
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
TABLE 5. SFM, IOM and IMM Line Cards Supported in 7450 ESS (Continued)
Alcatel-Lucent
Part #
10
Description
3HE05553BA
3HE05813AA
3HE05813BA
7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM L3BQ
3HE05814AA
3HE05814BA
3HE05895AA
7x50 48-port GE fixed port IOM (IMM) - L2HQ
3HE05895BA
7x50 48-port GE fixed port IOM (IMM) - L3BQ
3HE05896AA
7x50 48-port GE copper port IOM (IMM) - L2HQ
3HE05896BA
7x50 48-port GE copper port IOM (IMM) - L3BQ
3HE05898AA
3HE05898BA
3HE05899AA
3HE05899BA
3HE05950AA
7450 ESS-12 SF/CPM4 (ESS-12)
3HE05951AA
7450 ESS-7 SF/CPM4 (ESS-7)
3HE06318AA
7750 Multicore-CPU IOM3-XP
3HE06320AA
3HE06324AA
3HE06326AA
7x50 48-port GE Multicore-CPU SFP IMM - L3HQ
3HE06326BA
7x50 48-port GE Multicore-CPU SFP IMM - L3BQ
3HE06326CA
3HE06428AA
3HE06429AA
3HE06430AA
3HE06431AA
3HE06721AA
3HE06721BA
3HE06798AA
7750 1-port 40GE DWDM Tunable IMM - L3HQ
3HE06798BA
7750 1-port 40GE DWDM Tunable IMM - L3BQ
3HE06798CA
3HE07158AA
7x50 12-port 10GE FP3 SFP+ IMM - L3HQ
3HE07158BA
7x50 12-port 10GE FP3 SFP+ IMM - L3BQ
3HE07158CA
3HE07159AA
7x50 1-port 100GE FP3 CFP IMM - L3HQ
3HE07159BA
7x50 1-port 100GE FP3 CFP IMM - L3BQ
TABLE 5. SFM, IOM and IMM Line Cards Supported in 7450 ESS (Continued)
Alcatel-Lucent
Part #
Description
3HE07159CA
3HE07303AA
3HE07303BA
3HE07303CA
3HE07304AA
7x50 6-port 40GE FP3 QSFP IMM - L3HQ
3HE07304BA
7x50 6-port 40GE FP3 QSFP IMM - L3BQ
3HE07304CA
3HE07305AA
3HE07305BA
3HE07305CA
3HE08019AA
7x50 1-port 100GE DWDM Tunable FP3 IMM - L3HQ
3HE08019BA
7x50 1-port 100GE DWDM Tunable FP3 IMM - L3BQ
3HE08019CA
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
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
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
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
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
11
TABLE 6. 7710 SR Line Cards

Alcatel-Lucent
Part #
Description
3HE01014AA
7710 SR-c12 12 Gbps Control and Forwarding Module (CFM)
3HE01019AA
7710 SR-c12 Chassis Control Module (CCM)
3HE01024AA
7710 SR-c4 / SR-c12 MDA Carrier Module (MCM)
3HE02175AA
7710 SR-c4 9-Gbps Control and Forwarding Module (CFM)
3HE02181AA
7710 SR-c4 Chassis Control Module (CCM)
The following tables summarize the Media Dependent Adapters (MDAs), Integrated Service
Adapters (ISAs) and Compact Media Adapters (CMAs) supported in Release 11.0.R20.
TABLE 7. XMA and C-XMA Cards Supported in 7950 XRS
Alcatel-Lucent
Part #
Description
3HE06937AA
C-XMA - 7950 XRS 20-port 10GE SFP+ - IPCore
3HE06938AA
C-XMA - 7950 XRS 2-port 100GE CFP - IPCore
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+ - IPcore
3HE07297BA
XMA - 7950 XRS 40-port 10GE SFP+ - LSR
3HE07299AA
XMA - 7950 XRS 4-port 100GE CXP - IPcore
3HE07299BA
XMA - 7950 XRS 4-port 100GE CXP - LSR
3HE08214AA
C-XMA - 7950 XRS 6-port 40GE QSFP+ - IPCore
3HE08214BA
C-XMA - 7950 XRS 6-port 40GE QSFP+ - LSR
TABLE 8. MDAs, CMAs, and ISAs Supported in 7750 SR

SR-c12
SR-c4
SR-1
iom-20g-b
iom2-20g
iom3-xp/-b/-c
3HE00021AA
60-port 10/100TX MDA - mini-RJ21
3HE00023AA
20-port 100FX MDA - SFP
Alcatel-Lucent
Part #
12
Description
3HE00025AA
5-port GigE MDA - SFP
3HE00026AA
3HE00030AA
1-port 10GBASE-LW/LR MDA w/

optics - Simplex SC
3HE00031AA
1-port 10GBASE-EW/ER MDA w/

optics - Simplex SC
3HE00032AA
8-port OC-3c/STM-1c MDA - SFP
3HE00033AA
TABLE 8. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)
SR-1
iom-20g-b
iom2-20g
iom3-xp/-b/-c
SR-c4
3HE00037AA
SR-c12
Alcatel-Lucent
Part #
Description
3HE00038AA
3HE00043AA
3HE00044AA
3HE00048AA
1-port OC-192c/STM-64c MDA w/SR1/I-64.1 optic - Simplex SC
3HE00049AA
1-port OC-192c/STM-64c MDA w/IR2/S-64.2 optic - Simplex SC
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
3HE00708AA
3HE00709AA
1-port OC-192c/STM-64c MDA w/LR2/L-64.2 optic - Simplex SC
3HE00710AA
1-port 10GBASE-ZW/ZR MDA w/

optics - Simplex SC
3HE00714AA
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
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
13
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
14
iom3-xp/-b/-c
iom2-20g
iom-20g-b
SR-c4
4-port Channelized DS3/E3 ASAP

MDA
SR-1
SR-c12
3HE02501AA
Alcatel-Lucent
Part #
Description
3HE03610AA
5-port GE CMA-XP SFP
3HE03611AA
7750 SR 10-port GE - XP - SFP MDA
3HE03612AA
3HE03613AA
7750 SR 20-port GE - XP - Copper/TX

MDA
3HE03685AA
7750 SR 2-port 10GBASE - XP - XFP

MDA
3HE03686AA

MDA
3HE04179AA
7750 SR 10GBASE Tunable ZW/R

MDA
3HE04272AA
7750 SR 1-port OC-12/STM-4 CES

MDA
3HE04274AA

MDA
3HE04922AA
7750 SR / 7450 ESS Multiservice ISAa
3HE05142AA
7750 SR / 7450 ESS Multiservice ISA-E

(no encryption)a
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

MDA - SFP Rev B
3HE05946AA
7750 SR 4-port OC-48c/STM-16c POS

MDA - SFP Rev B
SR-1
iom-20g-b
iom2-20g
iom3-xp/-b/-c
SR-c4
SR-c12
Alcatel-Lucent
Part #
Description
3HE05947AA
7750 SR 2-port OC-192/STM-64 -XP XFP MDA
3HE06432AA
7750 SR 10-port GE SFP 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
Y
Y
Y
Y
Y
a. Refer to Usage Notes on page 139 for specifics.

Table 6
TABLE 9. MDAs and ISAs Supported in 7450 ESS

iom3-xp/-b/-c
Description
iom-20g-b
ESS-1
Alcatel-Lucent
Part #
3HE00021AA
7750 SR 60-port 10/100TX MDA mini-RJ21a
3HE00023AA
7750 SR 20-port 100FX MDA - SFPa
3HE00030AA
7750 SR 1-port 10GBASE-LW/LR

MDA w/ optics - Simplex SCa
3HE00031AA
7750 SR 1-port 10GBASE-EW/ER

3HE00033AA
7750 SR 16-port OC-3c/STM-1c MDA SFPa
3HE00037AA
7750 SR 8-port OC-12c/STM-4c MDA SFPa
3HE00038AA
7750 SR 16-port OC-12c/STM-4c MDA

- SFPa
3HE00043AA

- SFPa
3HE00044AA

- SFPa
15
TABLE 9. MDAs and ISAs Supported in 7450 ESS (Continued)
Description
iom3-xp/-b/-c
iom-20g-b
16
ESS-1
Alcatel-Lucent
Part #
3HE00048AA
7750 SR 1-port OC-192c/STM-64c

MDA w/SR-1/I-64.1 optic - Simplex
SCa
3HE00049AA

MDA w/IR-2/S-64.2 optic - Simplex
SCa
3HE00071AA

MDA - SFPb
3HE00074AA

MDA - SFPb
3HE00101AB
7750 SR 20-port 10/100/1000TX MDA

- RJ45a
3HE00230AA
3HE00231AA
3HE00232AA
3HE00233AA
3HE00234AB
20-port 10/100/1000TX MDA - RJ45
3HE00235AA
1-port 10GBASE-LW/LR MDA w/

optics - Simplex SC
3HE00236AA
1-port 10GBASE-EW/ER MDA w/

optics - Simplex SC
3HE00237AA
3HE00238AA
3HE00239AA
3HE00243AA
3HE00244AA
3HE00317AA
3HE00707AA
7750 SR 2-port 10GBASE MDA - XFPa
3HE00708AA
7750 SR 20-port GigE MDA - SFPa
3HE00709AA

MDA w/LR-2/L-64.2 optic - Simplex
SCa
3HE00710AA
7750 SR 1-port 10GBASE-ZW/ZR

3HE00714AA
7750 SR 1-port 10GBASE MDA - XFPa
Description
3HE01173AA
1-port 10GBASE-ZW/ZR MDA w/

optics - Simplex SC
3HE01197AA
7750 SR Versatile Services Module

(VSM)a
3HE01198AA
7450 ESS Versatile Services Module

(VSM)
3HE01364AA
7750 SR 4-port Channelized OC3/STM-1 (DS0) ASAP MDA - SFPb
3HE01532AA
3HE01616AA
7750 SR 10-port GigE MDA - SFP Rev

Ba
3HE01617AA
3HE02021AA
7750 SR 1-port 10GBASE + 10-port

GIGE MDAa
3HE02022AA
7450 ESS 1-port 10GBASE+10-port

GigE MDA
3HE02499AA
7750 SR 1-port Channelized OC12/STM-4 ASAP MDAb
3HE02500AA
7750 SR 12-port Channelized DS3/E3

ASAP MDAb
3HE02501AA
7750 SR 4-port Channelized DS3/E3

ASAP MDAb
3HE03078AA
7750 SR 1-port Channelized OC3/STM-1 CES MDAb
3HE03079AA
7750 SR 4-port CH OC3-1/STM-1 CES

SFP MDAb
3HE03611AA
7750 SR 10-port GE - XP - SFP MDAa
3HE03612AA
3HE03613AA
7750 SR 20-port GE - XP - Copper/TX

MDAa
3HE03614AA
7450 ESS 10-port GE - XP - SFP MDA
3HE03615AA
3HE03616AA
7450 ESS 20-port GE - XP - Copper/TX

MDA
3HE03685AA

MDAa
iom3-xp/-b/-c
iom-20g-b
ESS-1
Alcatel-Lucent
Part #
Y
Y
Y
Y
Y
Y
Y
Y
17
Description
iom3-xp/-b/-c
iom-20g-b
18
ESS-1
Alcatel-Lucent
Part #
3HE03686AA

MDAa
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

MDAa
3HE04181AA
7450 ESS 10GBASE Tunable ZW/R

MDA
3HE04272AA
7750 SR 1-port OC-12/STM-4 CES

MDAb
3HE04273AA
7450 1-port 10GBASE - XP - XFP

MDA
3HE04274AA

MDAa
3HE04922AA
7750 SR / 7450 ESS Multiservice ISAc
3HE05142AA
7750 SR / 7450 ESS Multiservice ISA-E

(no encryption)c
3HE05159AA
7450 SR 48-port 10/100/1000 - XP

MDA - mini-RJ21
3HE05160AA
7750 SR 48-port 10/100/1000 - XP

MDA - mini-RJ21a
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 Ba
3HE05944AA

MDA-SFP Rev Bb
3HE05945AA

MDA - SFP Rev Bb
3HE05946AA
7750 SR 4-port OC-48c/STM-16c POS

MDA - SFP Rev Ba
3HE05947AA
7750 SR 2-port OC-192/STM-64 -XP XFP MDAb
3HE06382AA
7450 ESS 16-port OC-3/12c STM-1/4c

POS MDA - SFP Rev B
Y
Y
Y
Y
Y
Y
Description
Y
iom3-xp/-b/-c
iom-20g-b
ESS-1
Alcatel-Lucent
Part #
3HE06383AA
7450 ESS 4-port OC-48c/STM-16c POS

MDA - SFP Rev B
3HE06432AA
7750 SR 10-port GE SFP HS-MDAv2a
3HE06434AA
7450 ESS 10-port GE SFP HS-MDAv2
3HE07282AA
7750 SR 2-port 10GE XFP + 12-port

GE SFP -XP MDAa
3HE07283AA
7450 ESS 2-port 10GE XFP + 12-port

GE SFP -XP MDA
3HE07284AA
7750 SR 12-port GigE - XP - SFP

MDAa
3HE07285AA
7450 ESS 12-port GigE - XP - SFP

MDA
a. Supported only with 7750 SR IOM3-XP in the 7450 ESS chassis, with or without
mixed-mode.
b. Supported only with 7750 SR IOM3-XP in the mixed-mode-enabled 7450 ESS
chassis.
c. Refer to Usage Notes on page 139 for specifics.
TABLE 10. 7710 SR MDAs and CMAs

Alcatel-Lucent
Part #
Description
3HE00021AA
3HE00023AA
3HE00025AA
3HE00032AA
3HE00043AA
3HE00071AA
4-port ATM OC-12c/STM-4c MDA - SFP
3HE00101AB
20-port 10/100/1000TX MDA - RJ45
3HE00708AA
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
3HE01024AA
MDA Carrier Module (MCM)
3HE01364AA
4-port Channelized OC-3/STM-1 (DS0) ASAP MDA - SFP
3HE01615AA
19
New Features in 11.0.R20
TABLE 10. 7710 SR MDAs and CMAs (Continued)

Alcatel-Lucent
Part #
Description
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
3HE03077AA
1-port Channelized OC-3/STM-1 CES CMA
3HE03079AA
4-port CH OC-3/STM-1 CES MDA
3HE03609AA
1-port GigE - XP - SFP CMA
3HE03611AA
10-port GE - XP - SFP MDA
3HE03612AA
20-port GE - XP - SFP MDA
3HE03613AA
20-port GE - XP - Copper MDA
3HE04272AA
1-port OC-12/STM-4 CES MDA
3HE05945AA
4-port ATM OC-12c/STM-4c MDA - SFP Rev B
3HE06521AA
2-port OC-3c/STM-1c/OC-12c/STM-4c CMA - SFP Rev B
3HE08220AA
8-port Channelized DS1/E1 CMA Rev B

There are no new major features in 11.0.R20. See page 93 for a list of Enhancements in
11.0.R20 and page 222 for a list of Resolved Issues in 11.0.R20.

The following section describes the new feature added since Release 11.0.R18 to the
Release 11.0.R19 of SR OS.
SF/CPM5 Hotswap
Support
20
Hot-swap support has been added to the following SF/CPM5 cards:
7750 SR SF/CPM5-12e, since Release 11.0.R15
7750 SR SFM5-12 + CPM5, since Release 11.0.R15
7750 SR SFM5-7 + CPM5, since Release 11.0.R15
7450 ESS SFM5-12 + CPM5, since Release 11.0.R15
7450 ESS SFM5-7 + CPM5, since Release 11.0.R15




Switch Fabric
Module 5 (SFM5)
Release 11.0.R15 introduces the Switch Fabric Module 5 (SFM5) for the 7450 ESS-7 and
7750 SR-7 (SFM5-7), for the 7450 ESS-12 and 7750 SR-12 (SFM5-12), and for the
7750 SR-12e (SFM5-12e). The SFM5 is a full-height card that is modular in design, provides
data plane functionality, and houses the pluggable CPM5 for investment protection. All
versions of SFM5 cards support hot-swap.
The SFM5-12e enables 400 Gbps line rate connectivity between all slots of the 7750 SR-12e
chassis when the chassis is equipped with all T3-based IOM/IMMs. The fabric cards are 3+1
redundant with an active-active load sharing design on the 7750 SR-12e.
Mini SFM5 for

SR-12e
Release 11.0.R15 introduces the Mini Switch Fabric Module 5 for the 7750 SR-12e platform.
The Mini SFM5 in conjunction with SFM5-12e for 7750 SR-12e enables 400 Gbps per slot with
all T3-based IOM/IMMs.
Control Processor
Module (CPM5)
Release 11.0.R15 introduces the Control Processor Module 5 (CPM5), a pluggable module for
all platforms, housed within the 7450 ESS SFM5-7/12 and 7750 SR SFM5-7/12/12e module.
The CPM5 provides management, security, and control-plane processing. Central processing
and memory are intentionally separated from the forwarding function on the interface modules.
Redundant CPMs operate in a hitless, stateful, failover mode. Central processing and memory
are intentionally separated from the forwarding function on the interface modules to ensure
utmost system resiliency.
21
1 PPS Output
Interface on CPM5
CPM5 provides a 1 PPS output signal representing the second rollover of the timescale of IEEE
1588 within the node. This signal conforms to G.703 Amendment 1 (08/2013) clause 17.2 1PPS
50 phase synchronization measurement interface.




48-port GE Rev-C
IMM
SR OS now supports the new variant of 48-port GE Multicore-CPU SFP IMM (IMM48-GESFP-C) which offers all of the features of the IMM48-GE-SFP-B. The Rev-C version uses the
T3 fabric interface with the same FP2-based forwarding planes as the IMM48-GE-SFP-B. It is
supported in the 7750 SR-7/12/12e and 7450 ESS-7/12 with SF/CPM4 or higher.

22

Line Card Filter
Policy
Release 11.0.R9 introduces the support for IPv4 ingress filter policy drop action conditioned
with packet-length gt value criterion. A packet matching an IPv4 ingress filter policy entry with
conditional drop action is dropped when the Total Length value in an outer IPv4 header is
greater than the value configured. If the packet-length condition is not met, the packet is
forwarded. Conditional drop packet-length functionality can be programed using the
config>filter>ip-filter>entry action drop packet-length gt packet-length-value command.
When the filter entry with conditional action is used as a mirror source, only packets satisfying
the match criteria and packet-length condition of an action are mirrored. When an entry is used
in Cflowd, packets are processed for Cflowd based on entry match criteria irrespective of
whether or not the packet-length action condition is met.
Packet-length condition with drop action is supported on FP2- and FP3- based line cards only
on 7450 ESS, 7750 SR, and 7950 XRS platforms. This feature is not supported in egress filters,
on FP1-based line cards, and on 7750 SR-c4/12 platforms. Deploying such a policy in those
scenarios may lead to undesired behaviors (packets matching an entry are always dropped or
always forwarded) and should be avoided.

IOM3-XP-C for SR7/12/12E, ESS-7/12
Support has been added for the IOM3-XP-C on the 7750 SR-7/12 and 7450 ESS-7/12 equipped
with SF/CPM4 only, and on the 7750 SR-12e platforms. This next generation of the IOM card
uses the new T3 fabric interface with the same FP2-based forwarding plane as the IOM3-XPB. It has an enhanced Multicore CPU and supports all MDA/MDA-XPs that are currently
available for IOM3-XP.

Advanced/
Intelligent power
management for
7950 XRS
The 7950 XRS routers support unique power management features by making use of the
intelligence built into the Advanced Power EQualization (APEQ) modules. The advanced
power management features in Release 11.0.R7 remove some of the strict guidelines associated
with power management in the previous releases and make it more granular and more flexible.
The advanced power management features supported in Release 11.0.R7 include:
23
Support for three (3) power-management nodes None, Basic and Advanced
User-configurable priorities for I/O modules
Provisioning of APEQs
User-configurable power safety level
Along with the support for associated configuration commands for these features, commands to
display the actual power consumed by the individual modules and the available power from the
APEQ modules are also supported. Appropriate log events are supported to alert the user of
changes in system power conditions.

The following section describes the new features added since Release 11.0.R5 to the
WAN-PHY Mode
for the 40-PORT
10GE SFP+ XMA
10-port 10GE SFP+
+ 20-port GE SFP
Multicore CPUbased IMM and 3port 40GE QSFP +
20-port GE SFP
Multicore CPUbased IMM
The 40-port 10GE SFP+ XMA for 7950 XRS now supports WAN-PHY mode.
Release 11.0.R6 introduces two new IMMs to the SR OS product family, the 10-port 10GE
SFP+ + 20-port GE SFP and a 3-port 40GE QSFP + 20-port GE Multicore-CPU-based IMMs:
128K queues flexibly configurable to any/all ports for ingress and/or egress
Can co-exist and are interoperable with all released IOMs/IMMs (must use a chassis mode
that aligns with the earliest generation of IOMs installed in the chassis)
Support for chassis mode D when a chassis is configured entirely with any combination of
IOM3-XPs and IMMs
Support for Alcatel-Lucent-sourced QSFP+, SFP+ and SFP optic modules (not included)
Power and cooling: an upgrade to PEM-3 and to the latest Enhanced Fan Tray is required
for systems utilizing these IMMs
Soft Reset support
Supported in the 7750 SR-7/12 and 7450 ESS-7/12 equipped with SF/CPM4 only, and in
the 7750 SR-12e.
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
license(s).
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-XP/IOM3-XP-B/IOM3-XP-C and newer IOM/IMM modules.
Note that even when only one IMM/IOM is deployed, impedance panels are required.
24
In-Service
Software Update
(ISSU) Across
Minor Releases on
the XRS
ISSU (in-service software update) across minor releases (Minor ISSU) allows in-service
software updates across maintenance releases (within the same major release) for systems with
dual-CPMs without requiring a reboot of the system. ISSU is comparable to performing a
controlled High-Availability switchover where the new image is loaded onto the standby CPM
which becomes master, and then upgrading the image on the other CPM.
With Release 11.0.R6, the support for Minor ISSU has been added for the 7950 XRS-20 and
XRS-16c platforms. The first Minor In-Service Software Upgrade path on the 7950 XRS
platform is from Release 11.0.R5 to Release 11.0.R6.
NETCONF
Release 11.0.R6 introduces the support for NETCONF. NETCONF is an IETF network
management protocol published as RFC 6241. It runs on top of the SSHv2 transport protocol
(SSHv2 is an existing protocol supported on SR OS) as specified in RFC 6242. NETCONF can
be used as an alternative to CLI or SNMP for managing an SR OS node. It is an XML-based
protocol used to configure network devices and uses RPC messaging for communicating
between a NETCONF client and the NETCONF server running on the SR OS node. An RPC
message and configuration data are encapsulated within an XML document. These XML
documents are exchanged between a NETCONF client and a NETCONF server in a
request/response type of interaction. The SR OS NETCONF interface supports both
configuration and retrieval of operational information. The SR OS NETCONF implementation
uses CLI at the content layer.
BGP IPv6Multicast Support
In Release 11.0.R6, the support for the IPv6-multicast address family has been added to BGP.
This capability allows IPv6 routes to be advertised via MP-BGP to populate the RPF table used
for IPv6 multicast.
PPTP ALG in NAT
PPTP Application-Level Gateway (ALG) is now supported in NAT implemented in an SR OS

router. PPTP ALG will allow control and data traffic to flow through the NAT MS-ISA. PPTP
sessions can be initiated from inside the NAT MS-ISA card. GRE traffic will be translated
through the NAT module only if the corresponding mapping exists. This mapping is established
during the PPTP call-establishment phase.
PPTP ALG is supported for LSN44, DS-Lite and L2-Aware NAT.
Stable Pool Sizing
IKEv2 Remote
Access Tunnels
Release 11.0.R6 supports the configuration of a stable-pool-sizing mode per Forwarding Path
(FP). This allows the buffer pool sizing to remain static as MDAs are added and removed, or as
ports are configured and removed. In stable-pool-sizing mode, each MDA is given an equal
share of the available buffers and each port is given its fair share of the total MDA buffering
based on its maximum bandwidth multiplied by the configured modify-buffer-allocation-rate
parameter. Consequently, as new MDAs or ports are configured, the per-MDA and per-port
pool sizes remain unchanged. Note that only when all ports are configured will the full buffer
pool capacity be assigned. Enabling stable-pool-sizing is mutually exclusive with named-poolmode on the card. This feature is supported on FP2- and higher-based line cards.
IPsec IKEv2 remote-access tunnel is now supported in Release 11.0.R6 and includes the
following features:
25
Authentication methods:
-
Pre-Shared-Key RADIUS
Certificate RADIUS
EAP/EAP-Only The system acts only as an EAP authenticator; the actual EAP
authentication happens between the IPsec client and RADIUS server. Supported EAP
methods are:
-
EAP-MD5
EAP-SIM
EAP-AKA
Internal address assignment via IKEv2 configuration payload
RADIUS-based address assignment
RADIUS accounting to report address usage
NAT-Traversal support
Option to match IDi to certain fields of peers certificate
MC-IPsec support with stateful redundancy support

IEEE1588 in VRF
In Release 11.0.R5, IEEE 1588 messaging support is also provided through VPRNs. This is in
addition to the existing support through the base-routing context. There remains only one IEEE
1588 clock within the node, but it can now be accessed through multiple routing contexts.
Note: IEEE 1588 is not supported on the management router instance.
Soft reset support

for 7950 XRS
In Release 11.0.R5, the soft reset option is now supported on the 7950 XRS. This feature allows
an XCM card to be reset with greatly reduced impact to traffic forwarding through the reset
card. This is performed by allowing traffic forwarding to continue while the line card's control
plane is reset and re-initialized. Forwarding is only affected while the forwarding engine itself
needs to be re-initialized. A Soft Reset is performed by issuing the clear card slot soft
command.
In-Service
Software Update
(ISSU) Across a
Major Release on
the XRS
Major ISSU (In-Service Software Update) allows in-service updates across a major release for
systems with dual-CPMs without requiring a reboot of the system. ISSU is comparable to
performing a controlled High-Availability switchover where the new image is loaded onto the
standby CPM which becomes master, and then upgrading the image on the other CPM.
26
With Release 11.0.R5, the support for Major ISSU has been added to the 7950 XRS-20 and
XRS-16c platforms. The first possible Major ISSU upgrade path will be from Release 11.0.R5
to a future 12.0 maintenance release.
In-Service
Software Update
(ISSU) Across
Minor Releases
ISSU (in-service software update) across minor releases (Minor ISSU) allows in-service
software updates across maintenance releases (within the same major release) for systems with
dual CPMs or CFMs without requiring a reboot of the system. ISSU is comparable to
standby CPM or CFM which becomes master, and then upgrading the image on the other CPM
or CFM. Minor ISSU does not apply to 7710 SR-c4, 7750 SR-1, 7750 SR-c4 or 7450 ESS-1.
Release 11.0.R5 does not support Minor ISSU on 7950 XRS. From Release 11.0.R4 onwards,
the terms Major ISSU and Minor ISSU are used to differentiate between ISSU across major
releases and maintenance releases within a major release respectively.
TACACS+
Interactive
Authentication for
Telnet
Release 11.0.R5 introduces the support for an interactive authentication scheme with
TACACS+. Interactive authentication allows the TACACS+ server to provide prompts and
messages to the user during the user and password queries. Interactive authentication allows the
use of one time password schemes (e.g., S/Key). The new behavior is enabled using the
interactive-authentication keyword in TACACS+ configuration.
Proprietary SNMP
Streaming
Mechanism
A proprietary SNMP request/response bundling via a TCP-based transport mechanism has been
added to SR OS for optimizing Alcatel-Lucent 5620 SAM management of SR OS nodes. In
higher latency networks, synchronizing SR OS MIBs from SAM via streaming takes less time
than synchronizing via classic SNMP UDP requests.
Improved Timing
Accuracy for OAM
Delay
Measurements
Release 11.0.R5 allows PTP to be the source of time for the system and OAM packet
timestamping. PTP has the capability to achieve a higher accuracy time recovery than NTP and
is recommended when one-way delay measurements are to be made across a network. In
addition to controlling system time and OAM timestamping, PTP is also used as an NTP
Stratum 0 source into the NTP process within the node.
A side effect of this allocation as an NTP Stratum 0 source is that the node will begin to
advertise itself as being at NTP Stratum 1 level, which may influence NTP peers and clients to
change their selected time source.
Auto-Creation of
Targeted LDP
Session
Release 11.0.R5 enables the automatic creation of a targeted Hello adjacency and LDP session
to a discovered peer. The user configures a targeted session peer parameter template and binds
it to a peer prefix policy.
Each application of a targeted session template to a given prefix in a prefix list will result in the
establishment of a targeted Hello adjacency to an LDP peer using the template parameters as
long as the prefix corresponds to a router-id for a node in the TE database. As a result of this,
the user must enable the traffic-engineering option in IS-IS or OSPF. The targeted Hello
adjacency will either trigger a new LDP session or will be associated with an existing LDP
session to that peer.
Up to five (5) peer prefix policies can be associated with a single peer template at any given
time. Also, the user can associate multiple templates with the same or different peer prefix
policies. Thus, multiple templates can match with a given peer prefix. In all cases, the targeted
session parameters applied to a given peer prefix are taken from the first created template by the
user. This provides a more deterministic behavior regardless of the order in which the templates
are associated with the prefix policies.
27
Each time the user executes the binding command, with the same or different prefix policy
associations, or the user changes a prefix policy associated with a targeted peer template, the
system re-evaluates the prefix policy. The outcome of the re-evaluation will tell LDP if an
existing targeted Hello adjacency needs to be torn down or if an existing targeted Hello
adjacency needs to have its parameters updated dynamically.
If a /32 prefix is added to (removed from) or if a prefix range is extended (reduced) in a prefix
list associated with a targeted peer template, the same prefix policy re-evaluation described
above is performed.
LSP Ping/Trace for
an LSP using a
BGP IPv4 label
route
Release 11.0.R5 extends the coverage of the LSP ping and trace tools to test connectivity of an
LSP using a BGP RFC 3107 label route. Support of the target FEC stack TLV of type BGP
Labeled IPv4 /32 Prefix as defined in RFC 4379 has also been added.
Extensions to LSP
Trace to Support
LSP Stitching and
LSP Hierarchy
Release 11.0.R5 extends the use of the LSP trace tool to cover the following scenarios:
OSPF Alternate
ABR
28
Note that only BGP label IPv4 /32 prefixes are supported since these are usable as tunnels in SR
OS. BGP label IPv6 /128 prefixes are not currently usable as tunnels on the 7x50 platform and
as such, are not supported in LSP ping/trace.
Full validation of an LDP FEC stitched to a BGP IPv4 label route In this case, the LSP
trace message is inserted from the LDP LSP segment or from the stitching point.
Full validation of a BGP IPv4 label route stitched to an LDP FEC This includes the case
of explicit configuration of the LDP-BGP stitching in which the BGP labeled route is
active in Route Table Manager (RTM) and the case of a BGP IPv4 label route resolved to
the LDP FEC due to the IGP route of the same prefix active in RTM. In this case, the LSP
trace message is inserted from the BGP LSP segment or from the stitching point.
Full validation of an LDP FEC that is stitched to a BGP LSP and stitched back into an LDP
FEC In this case, the LSP trace message is inserted from the LDP segments or from the
stitching points.
Full validation of an LDP FEC tunneled over an RSVP LSP using LSP trace In order to
properly check a target FEC that is stitched to another FEC (stitching FEC) of the same or
a different type, or that is tunneled over another FEC (tunneling FEC), it is necessary for
the responding nodes to provide details about the FEC manipulation back to the sender
node. This is achieved via the support of the new FEC stack change sub-TLV in the
Downstream Detailed Mapping TLV (DDMAP) defined in RFC 6424.
Release 11.0.R5 enhances the OSPFv2/v3 protocols to support the alternate ABR procedures
outlined in RFC 3509. There are two specific changes that have been implemented. First, the
ABR criteria has changed; a base router OSPF instance now considers itself an ABR if it is
actively attached (with an operational UP interface) to two or more different areas and one of
those areas is area 0 (the backbone). Second, the calculation of inter-area routes by an ABR has
changed; if the ABR has an area 0 adjacency, then it calculates inter-area routes using only
backbone summary LSAs, but if it lacks an area 0 adjacency, it calculates inter-area routes using
summary LSAs from all actively-attached areas. These changes help to avoid packet loss in
some inter-area scenarios.
BGP Graceful
Restart for IP-VPN
Release 11.0.R5 introduces BGP graceful-restart support (specifically, the receiving

router/helper role) for VPN-IPv4 and VPN-IPv6 routes. This means that forwarding based on
IP-VPN routes can continue uninterrupted if the peer router that announced them restarts using
Graceful Restart (GR) procedures.
BGP Update
Message Error
Handling
Enhancements
Release 11.0.R5 introduces a new configuration option for dealing with BGP UPDATE
message errors. The BGP standards have traditionally emphasized protocol correctness over
session resiliency in handling such errors. With BGP now being used in so many businesscritical applications, there are good reasons to consider relaxing some of the protocol
correctness constraints to avoid the disruptive effects of session resets. Release 11.0.R5
introduces a configuration option that enables the error handling procedures outlined in draftietf-idr-error-handling. In general, these procedures avoid sending a NOTIFICATION to the
peer sending the malformed UPDATE as long as the message can be parsed and has no lengthrelated errors.
BGP Graceful
Restart Support
for Notifications
Release 11.0.R5 enhances the BGP Graceful Restart implementation in SR OS so that it can be
used to preserve forwarding across Notification-triggered session resets, in alignment with
draft-ietf-idr-bgp-gr-notification-01. In order to use this feature, both peers (the one sending
and receiving the notification message) must advertise the capability.
BGP Peer Flap

Dampening
Release 11.0.R5 adds the support for a new damp-peer-oscillations command in the BGP
instance, group, and neighbor contexts (base router and VPRN). The damp-peer-oscillations
command tells BGP to hold the session in the idle state for exponentially increasing amounts of
time if there are repeat events that keep transitioning the state of the session from the established
to the idle state. In the idle state, BGP does not initiate or respond to attempts to establish a new
session. This supports the DampPeerOscillations FSM behavior described in section 8.1 of
RFC 4271.
Policy Evaluation
Command
In Release 11.0.R5, operators can now evaluate a routing policy against a BGP neighbor,
routing context or individual prefix before applying the policy to the neighbor or routing
context. This command will display prefixes that are rejected by a policy and what
modifications are made by a policy.

7950 XRS-16c
The Alcatel-Lucent 7950 XRS-16c introduced in Release 11.0.R4 delivers the scale, efficiency
and versatility of the eXtensible Routing System (XRS) technology in a medium density
package. The 7950 XRS-16c is based on a backplane design with all system cards located in the
front. The 7950 XRS-16c meets the core routing, MPLS switching and infrastructure services
needs of tier-2/3 service providers, and aggregation, metro core needs of tier-1 service
providers. The system is based on the same innovative and flexible FP family of network
29
processors as used on 7950 XRS-20. The 7950 XRS-16c shares the Compact XRS Media
Adapter (C-XMA) modules and the Advanced Power Equalization Modules (APEQ) with the
7950 XRS-20. The 7950 XRS-16c system is supported on the proven, resilient and feature-rich
SR OS which supports a full range of core and edge routing features.
The 7950 XRS-16c supports:
6-Port 40GE
QSFP+ C-XMA
7750 SR-c12 CFMXP-B
N+1 redundant power
1+1 redundant fans
1+1 redundant CPMs (Control and Processing Modules)
7+1 redundant SFMs (Switch Fabric Modules)
Hot-swappable system components and physical interfaces
The 6-port 40GE QSFP+ C-XMA for 7950 XRS introduced in Release 11.0.R4 is available in
either an LSR-only feature set or in a separately orderable IP-Core feature set variant. The 6port 40GE C-XMA offers six (6) QSFP ports, compatible with all Alcatel-Lucent family QSFP
modules (QSFPs not included).
Release 11.0.R4 introduces the new 7750 SR-c12 CFM-XP-B (Control and Forwarding
Module) designed to support IEEE 1588v2. To upgrade, contact your local Alcatel-Lucent
representative.
8-port Channelized
DS1/E1 CMA Rev
B
Release 11.0.R4 introduces the 8-port DS1/E1 CMA Rev B, which uses lead-free components
for RoHS compliance.
Embedded Filter
Policy Support for
ACL Filters
Release 11.0.R4 introduces a new type of ACL filter policies: embedded filter policies. An
embedded filter policy allows operators to define a common set of filter policy rules that can
then be embedded (nested) in one or more filter policies. Any embedded filter policy changes
are automatically applied to all filter policies that use that embedded filter policy and in turn,
are automatically downloaded to all line cards as required. Embedded filter policies are
supported for line card IP(v4) and IPv6 filter policies only.
BFD Over LAG

Links
In Release 11.0.R4, BFD has been enhanced to monitor LAG link members to speed up the
detection of link failures. To achieve this, when BFD is associated with an Ethernet LAG, BFD
sessions will be set up over each link member. A link will not be made operational in the
associated LAG until the associated BFD session is fully established if BFD over LAG links is
configured before the LAG is active.
If a LAG link is already in a forwarding state when BFD over LAG links is enabled, its
forwarding state will not be influenced by the uBFD session unless the uBFD session is fully
established. A setup timer is started to remove the link from the LAG in case the uBFD session
is not set up in time (the default value for this timer has no expiration time). The link member
will be removed from the operational state in the LAG if the BFD session fails.
When configuring the local and remote IP address for the BFD-over-LAG link sessions, the
local-ip parameter should always match an IP address associated with the IP interface to which
this LAG is bound. In addition, the remote-ip parameter should match an IP address on the
30
remote system and should also be in the same subnet as the local-ip address. If the LAG bundle
is re-associated with a different IP interface, the local-ip and remote-ip parameters should be
modified to match the new IP subnet. The IP address associated with the LAG does not have to
match an attached interface when the LAG has a Dot1Q encapsulation. This feature is only
supported on 7750 SR-7/12/12e, 7450 ESS-7/12, and all 7950 chassis.
In-Service
Software Update
(ISSU) Across a
Major Release
Major ISSU (In-Service Software Update) allows in-service updates across a major release for
systems with dual-CPMs without requiring a reboot of the system. ISSU is comparable to
standby CPM which becomes master, and then upgrading the image on the other CPM.
Major ISSU does not apply to 7710 SR-c4/c12, 7750 SR-1, 7750 SR-c4/c12 or 7450 ESS-1.
Note that Major ISSU for 7950 XRS platforms is introduced in Release 11.0.R5.
MS-ISA on 7450
Mixed-Mode for IPin-IP/GRE Tunnels
Release 11.0.R4 supports IP-in-IP and GRE tunnels running on an MS-ISA on a 7450 chassis
in Mixed-Mode. Tunnel Services application license is required to enable the feature.
ANCP on Compact
Flash
In Release 11.0.R4, ANCP information is now backed up in the ESM persistence files on the
compact flash. This allows the ANCP database to remain persistent during a software upgrade
or a nodal reboot.
RADIUS
Accounting-Stop
in Authentication
failure scenarios
In scenarios where RADIUS authentication is used for PPPoE sessions, an accounting stop
message can be generated to notify the RADIUS servers in case of an authentication failure.
The failure events are categorized as follows:
on-request-failure all failure conditions between the sending of an Access-Request

and the reception of an Access-Accept or Access-Reject
on-reject when an Access-Reject is received
on-accept-failure all failure conditions that appear after receiving an Access-Accept

and before successful instantiation of the host or session
In Release 11.0.R4, each of the categories can be enabled separately in the RADIUS
authentication policy using the send-acct-stop-on-fail CLI command. Local user database
(LUDB) pre-authentication is required to learn the RADIUS accounting server to use for the
Accounting-Stop on failure messages.
RADIUS FramedIPv6-Route
support and
Framed-Route
enhancements
As an alternative to Prefix Delegation, it is now possible in Release 11.0.R4 to associate an IPv6

managed route with an IPv6 routed-subscriber WAN host (DHCP IA-NA or SLAAC) using the
[99] Framed-IPv6-Route RADIUS attribute.
Metric, tag and protocol preference can now be specified for both IPv4 and IPv6 RADIUS
learned managed routes. The format of the [22] Framed-Route RADIUS attribute is enhanced
and equal to the format of the [99] Framed-IPv6-Route: ip-prefix/prefix-length gatewayaddress [metric] [tag tag-value] [pref preference-value]
Valid RADIUS learned managed routes can now be included in RADIUS accounting messages
with the following configuration:
configure subscriber-mgmt radius-accounting-policy include-radius-attribute framed-route
31
802.3ah and ISSU
configure subscriber-mgmt radius-accounting-policy include-radius-attribute framed-ipv6route
In Release 11.0.R4, support has been added to allow the operator to enable a vendor-specific
grace transmission during an ISSU upgrade. This allows a vendor-specific message to be
included in the Informational PDU that is transmitted as part of the 802.3ah OAM protocol
during an ISSU upgrade on the 7450 ESS-7/12 and 7750 SR-7/12. The grace announcement
allows for an extension of the session timeout.
Sub-Second CCMEnabled MEPs
The lowest MD-Level configured MEP is no longer the only MEP that can support sub-second
CCM intervals. In Release 11.0.R4, higher MD-Level MEPs can be configured as the subsecond CCM-enabled MEP as long as no lower MD-Level MEP has CCM-enabled, or is
receiving CCM PDUs from a peer. All other requirements remain in place for sub-second CCMinterval-based MEPs.
NTPv4 over IPv6
In Release 11.0.R4, NTP now supports communication using IPv6 in addition to IPv4. Unicast
Client and Unicast Server and Symmetric Active modes of operation are supported over IPv6.
TCP/UDP port
range match
criterion support
in CPM IPv4 and
IPv6 filter policies
In Release 11.0.R4, support has been added to specify port ranges within a single filter policy
entry for CPM IPv4 and IPv6 source port and destination port match criteria, similar to line card
filter policies.
Logical OR
enhancement for
TCP/UDP source
and destination
ports match
criterion in CPM
IPv4 and IPv6 filter
policy
In Release 11.0.R4, support has been added for the new port match criterion in CPM IPv4 and
IPv6 filter polices. The new match criterion allows an operator to specify a single filter policy
entry with a port criterion defining one or more TCP/UDP port values. The entry will trigger its
action if a TCP/UDP packet matches the port value or values on either the source port field, the
destination port field, or both.
Auto-generation of
filter-policy
address prefix
match lists for
Line Card ACL
policies
Release 11.0.R1 introduced the capability to auto-generate address prefixes inside IPv4 and
IPv6 address prefix match lists used in CPM filters.
32
In Release 11.0.R4, SR OS allows operators to auto-generate address prefixes for IP(v4) and
IPv6 address prefix match lists entries based on BGP peer configuration and to use those match
lists in line card filter policies. When the BGP configuration changes, the match list(s) are autopopulated with the BGP neighbor address prefixes changes and, in turn, filter policies that use
those match lists are updated as required.
SAP & MPLS SDP

Binding Loopback
with MAC Swap
Release 11.0.R4 provides a means to place an Ethernet SAP or MPLS SDP binding in a mode
that will loop received packets back in the direction of the source. Both ingress and egress
loopbacks are available for Epipe, PBB Epipe, VPLS and I-VPLS Ethernet SAPs, and MPLS
SDP Bindings. Optionally, MAC-swapping functions are available to override the source MAC
address in the reflected packet. This feature requires IOM3-XP/IMM or higher.
Routing Policy
Subroutines
In Release 11.0.R4, it is now possible to reference a routing policy from within another routing
policy to construct powerful subroutine-based policies.
A single level of policy subroutines is supported. Policy subroutines may evaluate true or false
through matching and policy entry actions. A policy entry action of accept will evaluate true
while a policy entry action of reject will evaluate as false.
To support this functionality, a new policy from match type is introduced that references the
sub-policy.
Support for
Routed VPLS on
7950 XRS
In Release 11.0.R4, the same capability and scaling for both Routed VPLS and Routed I-VPLS
on the 7750 SR are now supported on 7950 XRS. This includes supporting RSTP on Routed
VPLS and Routed I-VPLS.
Support for Apipe

on 7950 XRS
Apipe service capability has now been added to the 7950 XRS platform with Release 11.0.R4
(note that ATM SAPs are not supported on the 7950 XRS platform, but pseudowire-switching
is supported).
CMPv2
Release 11.0.R4 supports CMPv2, which stands for Certificate Management Protocol version 2
(RFC 4210); it is a protocol between a Certificate Authority (CA) and end entities, and it
provides multiple certificate management functions such as certificate enrollment, certificate
update, etc.
Release 11.0.R4 supports the following CMPv2 operations:
Support for RIP on

7950 XRS
Initial Registration
Key Pair Update
Certificate Update
Polling
The same capability and scaling for RIP on the 7750 SR are now supported on 7950 XRS.
BGP-AD for RVPLS
Release 11.0.R4 adds BGP Auto-Discovery (BGP-AD) support for Routed VPLS and Routed
I-VPLS. BGP-AD for LDP VPLS is an already-supported framework for automatically
discovering the endpoints of a Layer-2 VPN, offering an operational model similar to that of an
IP-VPN.
Unnumbered
Interface Support
in LDP
Release 11.0.R4 allows LDP to establish Hello adjacencies and to resolve unicast and multicast
FECs over unnumbered LDP interfaces.
33
Hello adjacencies will be brought up using link Hello packets with the source IP address set to
the interface-borrowed IP address and a destination IP address set to 224.0.0.2. The transport
address for the TCP connection, which is encoded in the Hello packet, will always be set to the
LSR-ID of the node. The source and destination IP addresses of LDP packets are the transport
addresses (i.e., LDP LSR-IDs) of the LDP peers.
A FEC can be resolved to an unnumbered interface in the same way as it is resolved to a
numbered interface. The outgoing interface and next-hop are looked up in RTM cache. The
next-hop consists of the router-id and link identifier of the interface at the peer LSR. This feature
supports resolving an LDP FEC over ECMP next-hops consisting of a mix of unnumbered and
numbered interfaces. All LDP FEC types are supported.
This feature also extends the support of lsp-ping, p2mp-lsp-ping, and ldp-treetrace to test an
LDP unicast or multicast FEC that is resolved over an unnumbered LDP interface.
LDP Graceful
Handling of
Resource
Exhaustion
Two new features enhance the behavior of LDP when a data path or a CPM resource required
for the resolution of a FEC is exhausted. In releases prior to Release 11.0.R4, the LDP module
shuts down. The user was required to fix the issue causing the FEC scaling to be exceeded and
to restart the LDP module by executing the no shutdown command.
The first feature implements a base graceful-handling capability by which the LDP interface to
the peer, or the targeted peer in the case of Targeted LDP (T-LDP) session, is shutdown. If LDP
tries to resolve a FEC over a link or a T-LDP session and it runs out of data path or CPM
resources, it will bring down that interface or targeted peer, which will bring down the Hello
adjacency over that interface to all link LDP peers or to the targeted peer. The interface is
brought down in LDP context only and is still available to other applications such as IP
forwarding and RSVP LSP forwarding.
After taking action to free up resources, the user is required to manually perform a "no
shutdown" command on the interface or the targeted peer to bring it back into operation. This
re-establishes the Hello adjacency and resumes the resolution of FECs over the interface or to
the targeted peer.
The second feature is an enhanced graceful-handling capability that is supported only among
SR OS-based implementations. If LDP tries to resolve a FEC over a link or a targeted session
and it runs out of data path or CPM resources, it will put the LDP/T-LDP session into the
overload state. As a result, it will release to its LDP peer the labels of the FECs that it could not
resolve and will also send an LDP notification message to all LDP peers with the new status of
overload for the FEC type which caused the resource issue. The notification of overload is per
FEC type (i.e., unicast IPv4, P2MP mLDP etc.), and not per individual FEC. The peer that
caused the overload and all other peers will stop sending any new FECs of that type until this
node updates the notification stating that it is no longer in overload state for that FEC type. FECs
of this type previously resolved and other FEC types to this peer and all other peers will continue
to forward traffic normally.
After taking action to free up resources, the user is required to manually clear the overload state
of the LDP/T-LDP sessions towards its peers. The enhanced mechanism will be enabled instead
of the base mechanism only if both LSR nodes advertise this new LDP capability at the time the
LDP session is initialized. Otherwise, they will continue to use the base mechanism.
34
mLDP Fast
Upstream
Switchover
Release 11.0.R4 enables a downstream LSR of a multicast LDP (mLDP) FEC to perform a fast
switchover and source the traffic from another upstream LSR while IGP and LDP are
converging due to a failure of the upstream LSR that is the primary next-hop of the root LSR
for the P2MP FEC. It provides an upstream Fast-Reroute (FRR) node-protection capability for
the mLDP FEC packets. It does it at the expense of traffic duplication from two different
upstream nodes into the node that performs the fast upstream switchover.
When this command is enabled and LDP is resolving an mLDP FEC received from a
downstream LSR, it checks if an ECMP next-hop or an LFA next-hop exists to the root LSR
node. If LDP finds one, it programs a primary ILM on the interface corresponding to the
primary next-hop and a backup ILM on the interface corresponding to the ECMP or LFA nexthop. LDP then sends the corresponding labels to both upstream LSR nodes. In normal operation,
the primary ILM accepts packets while the backup ILM drops them. If the interface or the
upstream LSR of the primary ILM goes down causing the LDP session to go down, the backup
ILM will then start accepting packets.
In order to make use of the ECMP next-hop, the user must configure the ECMP value in the
system to at least two (2). In order to make use of the LFA next-hop, the user must enable the
LFA option under the IGP instance.
This feature is supported on all chassis except the 7450 ESS-1, 7750 SR-1, and 7710 SR-c4/c12.
All network IP interfaces are required to be on IOM3/IMM ports.
L2TPv3 SDP
Transport Over
IPv6 for Epipe
Services
Release 11.0.R4 introduces support for Layer-Two Tunneling Protocol version 3 (L2TPv3)
SDPs using the IPv6 protocol as the underlying transport mechanism. This SDP type only
supports Epipe services.
This implementation is intended as a light-weight alternative to MPLS- or GRE-transported
SDPs in networks that run as IPv6-only topologies and require L2/Epipe services in conjunction
with native IPv6 routing.
Configuring an L2TPv3 SDP requires:
far-end IPv6 address
local-end IPv6 address (must be unique; must be configured on a loopback interface as a

/128)
signaling to be off
the end-to-end network MTU to be able to support the Epipe payload, L2TPv3 and IPv6
headers.
Configuring the spoke-SDP binding in the Epipe service requires:
a VC-ID of any value to be used, as it is ignored by the system
an optional ingress cookie to be used, which is a 64-bit colon-separated value. If no cookie

is configured then a default value of zero is used
an optional egress cookie to be used, which is a 64-bit colon-separated value. If no cookie

is configured then a default value of zero is used.
35
Exclusive editing
for policy
configuration
Starting in Release 11.0.R4, operators can now set an exclusive lock on policy edit sessions.
When the exclusive flag is set by an operator that is editing the policy, other users (console or
SNMP) are restricted from being able to begin, edit, commit, or abort the policy. An
administrative override is made available to reset the exclusive flag in the event of a session
failure.
BGP Deterministic
MED
Release 11.0.R4 introduces a configurable change to the BGP best-path selection algorithm that
makes it more deterministic when some of the paths being compared come from different
neighboring autonomous systems and/or some do not have a MED attribute.
Support of IPv4
address family in
OSPFv3
Release 11.0.R4 introduces the support for the IPv4 address family within the OSPFv3 protocol.
In releases prior to Release 11.0.R4, on dual-stack interfaces using the OSPF protocol, it was
necessary to run both OSPFv2 and OSPFv3 to dynamically exchange routing information for
IPv4 and IPv6 routes. With this extension, both IPv4 and IPv6 routing information can be
exchanged via the single OSPFv3 protocol, reducing administrative and operational overhead
in configuration and network control traffic.
IS-IS Link Groups
Release 11.0.R4 introduces the ability to configure link-groups within the IS-IS protocol. IS-IS
link groups permits an operator to group multiple member interfaces that should be treated as a
single virtual link for ECMP purposes.
When configuring a virtual group, the operator may configure the minimum number of
members for the link and the group metric offset.
IGP Metric Link

Quality
Adjustment
In Release 11.0.R4, IGP Metric Link Quality Adjustment allows an operator to configure IGP
metrics to be adjusted based on Bit Error Rate (BER) measurements observed on DWDM
interfaces.
Multi-Topology ISIS
Release 11.0.R4 introduces Multi-Topology IS-IS (MT-ISIS) support within SR OS. This
feature allows for the creation of different topologies within IS-IS that contribute routes to a
specific route tables for IPv4 unicast, IPv6 unicast, IPv4 multicast and IPv6 multicast. This
capability allows for non-congruent topologies between these different routing tables. As a
result, networks are able to control which links or nodes are to be used for forwarding different
types of traffic.
MPLS Transport
Profile (MPLS-TP)
Release 11.0.R4 introduces the MPLS Transport Profile (MPLS-TP). MPLS-TP is intended to
allow MPLS to be operated in a similar manner to existing transport technologies with static
configuration of transport paths (i.e., no requirement for a dynamic control plane), in-band
proactive and on-demand operations and maintenance (OAM), and protection mechanisms that
do not rely on a control plane (e.g., RSVP-TE) to operate. The SR OS node can operate both as
an LER and LSR for MPLS-TP LSPs, and as a T-PE and S-PE for MPLS-TP PWs. It can
therefore act as a node within an MPLS-TP network, or as a gateway between MPLS-TP and
IP/MPLS domains.
In Release 11.0.R4, the SR OS node supports bidirectional co-routed MPLS-TP LSPs and PWs.
MPLS-TP identifiers, OAM and protection mechanisms defined in IETF RFCs are supported.
This includes:
36
MPLS-TP identifiers for nodes, LSPs, and PWs
OAM and protection using the MPLS-TP Generic Associated Channel (G-ACh) with both
IP and non-IP encapsulation (as applicable)
Proactive CC/V for MPLS-TP LSPs using BFD
On-Demand CV for MPLS-TP LSPs and PWs using LSP Ping/Trace and VCCV
Ping/Trace
Linear protection for MPLS-TP LSPs, with the ability to configure a working path and a
protect path for each LSP
Static PW status signaling, (RFC 6478), with support for PW redundancy, MC-LAG, MCAPS BGP multi-homing, and active/standby dual homing into IES/VPRN/VPLS
MPLS-TP also introduces the capability to configure an unnumbered MPLS-TP interface type
with a unicast, multicast or broadcast next-hop MAC address and without a configured IP
address. MPLS-TP LSPs can also use conventional numbered and unnumbered IP interfaces.
The following services are supported with MPLS-TP in Release 11.0.R4: Epipe, Cpipe and
Apipe VLLs, Epipe spoke-SDP termination on VPLS (including I-VPLS, B-VPLS, R-VPLS),
and Epipe spoke-SDP termination on IES/VPRN.
MPLS-TP supports mirroring, and on 7750 SR-7/12/12e, 7750 SR-c4/c12, and 7450 ESS6/6v/7/12 with IOM3/IMM or higher, but with the following restrictions:
Local pool
management for
PPPoX and PPPoE
SLAAC hosts
Supported on Ethernet ports only
Requires SF/CPM3 for full-scaled BFD
Requires network chassis mode D
In Release 11.0.R4, the IP addresses for PPPoX and PPPoE SLAAC hosts (non-DHCP clients)
can now be allocated from local pools on the SR OS node without using an internal DHCP client
to bridge the gap between the non-DHCP clients and the DHCP leases in the DHCP server.
The IP addresses allocated from the local pools will not have DHCP lease states but will instead
be tied directly to the PPP session.
The local DHCPv6 pool can also be used to assign IPv6 prefixes to PPPoE SLAAC hosts.
During authentication, RADIUS can return a pool name VSA. The pool name should match
a pool name configured on the DHCPv6 local server. A prefix will then be derived from the
selected pool for the SLAAC host.
Local pool
management for
IPoE WAN hosts
Release 11.0.R4 adds the support for managing local pools for IPoE WAN hosts for operators
who want to provide a fixed IA_PD prefix for their subscribers while using a local DHCPv6
server to assign IA_NA addresses. A subscriber can then receive a lifetime permanent IA_PD
prefix from their service provider. IA_NA address, mainly for CPE management purposes with
no address stickiness requirement, can use the dynamic DHCP server.
This feature can be triggered by RADIUS or Local User Database (LUDB). If RADIUS is used,
VSAs should return a pool name for the IA_NA and a static prefix for the IA_PD. If LUDB
is used, VSAs should have a configured IA_NA pool name and a configured IA_PD prefix.
DS-Lite and NAT64

Fragmentation
In Release 11.0.R4, downstream IPv6 fragmentation in DS-Lite and NAT64 can now be
optionally enabled. The fragmentation in IPv6 packets can only be performed at the source of
the IPv6 traffic, which is in the MS-ISA for DS-Lite and NAT64.
37
Fragmentation of IPv4 packets, before they enter the NAT function in the MS-ISA, continues
to be performed by the IOM forwarding plane.
H-QoS Adjustment
per Vport
In Release 11.0.R4, modification of a Vport bandwidth based on received IGMP joins/leaves in

scenarios where unicast and multicast subscriber traffic paths are disjoined within an SR OS
node is now supported. This enhancement can be used in deployments where a Vport represents
a bandwidth management point with a shared medium in which only a single multicast stream
is sent for all subscribers connected to this shared medium (for example, a PON port in the
access part of the network). The aggregate bandwidth of the Vport is adjusted when the first
IGMP join per multicast group and last IGMP leave per multicast group are received by the
subscribers associated with that Vport. In this fashion, the bandwidth allocated for unicast
traffic flowing through the Vport will gain awareness of the multicast bandwidth that is used by
the physical construct (PON) represented by the Vport.
The Vport rate that will be affected by this functionality depends on the configuration:
In case the agg-rate-limit within the Vport is configured, its value will be modified based
on the IGMP activity associated with the subscriber under this Vport.
In case that the port-scheduler-policy within the Vport is referenced, the max-rate defined
in the corresponding port-scheduler-policy will be modified based on the IGMP activity
associated with the subscriber under this Vport.
This feature is supported in ESM only.

LNS Reassembly
Release 11.0.R4 introduces the support for reassembly in the LNS function on a set of MS-ISAs
in a nat-isa group. Incoming traffic is redirected via ip-filters based on any supported matching
criteria. Once the traffic satisfies matching criteria in the ip-filter, it will be forwarded to the
reassembly function, regardless of whether the traffic is fragmented or not. Fragmented traffic
will be reassembled before it is recirculated into the same routing context in which the LNS
function resides. Non-fragmented traffic will be recirculated into the same routing context
without any further action taken in the reassembly MS-ISA.
Deterministic DSLite
Release 11.0.R4 introduces deterministic DS-Lite, in which the subscribers (IPv6 addresses or
prefixes) are mapped into outside IPv4 addresses and corresponding port-blocks based on a
deterministic algorithm. The inverse mapping that reveals the DS-Lite subscriber identity
behind the NAT is based on the reversal of this algorithm. This eliminates the need for logging.
A single port-block can be deterministically allocated to a DS-Lite subscriber. In case that the
DS-Lite subscriber exhausts all ports in this deterministic port-block, a dynamic port-block can
be optionally allocated to the DS-Lite subscriber. This capability allows for the dynamic
expansion of the number of ports that the DS-Lite subscriber can use. This subsequent dynamic
port-block allocation is non-deterministic and thus will be logged. Similarly, all static port
forwards are logged.
The reverse query that reveals the identity of the DS-Lite subscriber can be performed directly
via CLI (or MIB), or it can optionally be performed off-line via a Python script that is
automatically generated on the node and then manually exported to an external storage.
38
NAT-Traversal
Support for IKEv2
LAN-to-LAN
Tunnel
NAT-Traversal support has been added to IKEv2 LAN-to-LAN tunnel in Release 11.0.R4. This
feature allows IKEv2 IPsec tunnel to traverse through NAT devices.
DHCPv6 Relay
Enhancements on
Non-ESM
Interfaces
In Release 11.0.R4, the following new configurable functions have been added to the DHCPv6
relay on the access interface (non-ESM) of a VPRN/IES service:
DHCPv4/v6 Server
Multi-Homing
Enhancements
Creation of routes based on the IA_PD/IA_NA/IA_TA prefix option in relay-reply

message
Creation of black hole routes based on OPTION_PD_EXCLUDE in IA_PD in relay-reply

message
In Release 11.0.R4, the following functionality is now supported in redundant DHCP server
configuration:
Access-driven failover mode for IPv4 address-ranges and IPv6 prefixes in a DHCPv4/v6
pool Access-driven DHCP dual-homing model relies on the protection mechanism in
the access part of the network (SRRP/MC-LAG) to provide the connectivity to only one
DHCP server per DHCP address-range/prefix at any given time. This will ensure uninterrupted IP address/prefix delegation from the shared IP address-range/prefix in case of
a failure in the access (SRRP/MC-LAG switchover).
In this model, the same IP address-range/prefix is configured as access-driven on both
DHCP servers within the redundant pair of DHCP servers. This model makes each DHCP
server the owner of the same IP address-range/prefix, allowing it to delegate IP
addresses/prefixes from it, regardless of whether the interconnection link between DHCP
servers is operational or not or in other words, regardless of whether DHCP leases are
being synchronized or not between the two DHCP servers. For this reason, this DHCP
redundancy model requires that only one DHCP server per IP address-range/prefix is
reachable at any given time from the access side. This can be ensured by deploying one of
the existing path protection mechanisms (SRRP/MC-LAG) in the access part of the network. Otherwise, the IP address duplication may occur in cases where DHCP or PPP clients have simultaneous access to the shared IP address-range/prefix on both DHCP servers.
The possible IP address duplication is caused by the fact that both DHCP servers may
assign the same IP address from the shared IP address-range/prefix to two different clients
before the DHCP lease state becomes synchronized between the two nodes.
The configured DHCP-server IP addresses (the addresses to which the DHCP servers are
attached) must be the same IP address on both nodes in this mode of operation. This will
ensure that each DHCP server is serving local requests and is not relaying them to the
redundant peer. Relaying the DHCP requests between the DHCP redundant peers would
increase the likelihood of IP lease duplication. Additionally, the same DHCP-server IP
address on both nodes will ensure the successful renewal of IP leases in case of the
SRRP/MC-LAG switchover.
Fast takeover of IP address-ranges/prefixes designated as remote This functionality

allows the remote IP address-range/prefix to be used for new lease delegation immediately
following the failure of the intercommunication link (MCS link) between the two chassis.
Without the fast takeover, the new IP addresses from the remote IP address-range/prefix
can be delegated only once the MCLT period has expired while the intercommunication
link is in the PARTNER-DOWN state.
39
In this model, the failure of intercommunication link must be caused by failure of one of
the redundant nodes (entire node is down) and not by the failure of the links connecting the
two redundant nodes. In other words, if both DHCP server nodes are active and being able
to delegate new IP address leases while the lease synchronization is broken (due to the
intercommunication link failure), the IP lease duplication may occur. To prevent this duplication, the logical intercommunication link between the two nodes must be well-protected
with multiple physical paths between the two nodes.
Automatic
Creation of RSVP
Mesh and OneHop LSPs
Release 11.0.R4 enables the automatic creation of an RSVP point-to-point LSP to a destination
node which router-id matches a prefix in the specified peer prefix policy. This LSP type is
referred to as auto-LSP of type mesh.
The user can associate multiple templates with same or different peer prefix policies. Each
application of an LSP template with a given prefix in the prefix list will result in the instantiation
of a single CSPF-computed LSP primary path using the LSP template parameters as long as the
prefix corresponds to a router-id for a node in the Traffic Engineering (TE) database. Each
instantiated LSP will have a unique LSP-id and a unique tunnel-id.
Up to five (5) peer prefix policies can be associated with a given LSP template at all times. Each
time the user executes the above command, with the same or different prefix policy
associations, or the user changes a prefix policy associated with an LSP template, the system reevaluates the prefix policy. The outcome of the re-evaluation will tell MPLS if an existing LSP
needs to be torn down or a new LSP needs to be signaled to a destination address which is
already in the TE database.
If a /32 prefix is added to (removed from) or if a prefix range is expanded (shrunk) in a prefix
list associated with a LSP template, the same prefix policy re-evaluation described above is
performed.
If the one-hop option is specified instead of a prefix list, this command enables the automatic
signaling of one-hop point-to-point LSPs using the specified template to all directly connected
neighbors. This LSP type is referred to as auto-LSP of type one-hop. Although the provisioning
model and CLI syntax differ from that of a mesh LSP only by the absence of a prefix list, the
actual behavior is quite different. When the above command is executed, the TE database will
keep track of each TE link which comes up to a directly connected IGP neighbor which routerid is discovered. It then instructs MPLS to signal an LSP with a destination address matching
the router-id of the neighbor and with a strict hop consisting of the address of the interface used
by the TE link. Thus the auto-lsp command with the one-hop option will result in one or more
LSPs signaled to the neighboring router.
Signaling a mesh or a one-hop LSP is triggered when the router with a router-id matching a
prefix in the prefix list appears in the TE database. The auto-LSP is installed in the Tunnel Table
Manager (TTM) and is available to applications such as LDP-over-RSVP, resolution of BGP
labeled routes, resolution of BGP, IGP, and static routes. The auto-LSP can also be used for
auto-binding by services such as VPRN, BGP-AD VPLS, and FEC129 VLL service. The autoLSP is, however, not available to be used in a provisioned SDP for explicit binding by services.
An auto-created mesh or one-hop LSP can have egress statistics collected at the ingress LER by
adding the egress-statistics node configuration into the LSP template. The user can also have
ingress statistics collected at the egress LER using the same ingress-statistics node in CLI used
with a provisioned LSP. The user must specify the full LSP name as signaled by the ingress LER
in the RSVP session name field of the Session Attribute object in the received PATH message.
40
RSVP Inter-Area
P2MP LSP
Release 11.0.R4 introduces inter-area traffic engineering (TE) support to the S2L path of an
RSVP P2MP LSP instance. This is based on the automatic ABR selection implementation. It
also extends the support to the S2L path of a P2MP LSP instance of the ABR FRR link
protection using a dynamic facility-bypass backup LSP.
Enhancements to
Unnumbered
Interface Support
in RSVP
In Release 11.0.R4, the following features can be enabled on RSVP P2P and P2MP LSPs over
a path with unnumbered interfaces:
Enhancements to
Admin-Group
Support on
Bypass
Soft pre-emption of LSP path using unnumbered interface
Inter-area LSP
RSVP refresh reduction on an unnumbered interface.
In Release 11.0.R4, the support of admin-group with facility-bypass backup LSP has been
extended to the following items:
LSP template for auto-created RSVP P2P LSP in intra-area TE
S2L path of a provisioned RSVP inter-area P2MP LSP instance
LSP template for an S2L path of an RSVP inter-area P2MP LSP instance.
BGP VPWS
In Release 11.0.R4, BGP-VPWS services have been extended to support BGP multi-homing
using an active and a standby pseudowire between a remote PE and a pair of dual-homed PEs.
The site-preference parameter can be used to set the VPLS preference in both the BGP multihoming and BGP-VPWS updates in order to influence the designated forwarder election on
multi-homing PEs and the active pseudowire selection on remote PEs towards multi-homing
PEs, respectively. Consequently, attempts to modify the BGP local-preference using an export
policy when the VPLS preference is non-zero are ignored.
WLAN-GW :
support for IPv6
only APs and
CPEs
In order to accommodate IPv6-only access point (AP)/CPEs, IPv6 soft GRE tunnel transport
and IPv6 client-side support for RADIUS-proxy have been added. The support for IPv6 GRE
tunnels require configuration of local IPv6 tunnel endpoint address under soft-gre configuration
on the group-interface. A single endpoint instance can have both IPv4 and IPv6 address
configured, and inter-AP mobility between IPv4 and IPv6 only APs is supported in this
scenario.
RADIUS proxy is extended to listen for incoming IPv6 RADIUS messages from IPv6 RADIUS
clients on AP/CPEs. The listening interface that the RADIUS proxy binds to must be configured
with an IPv6 address. There is no change in existing RADIUS proxy functions for IPv6
RADIUS clients. In Release 11.0.R4, no caching and correlation is supported with RADIUS
proxy for IPv6 capable UEs (i.e., the RADIUS proxy is solely for DHCPv4-based UEs behind
IPv6 only AP/CPEs).
SPB Static MAC

and ISIDs
Release 11.0.R4 enables an SPBM interface on a SAP or SDP to have static B-MACs and static
ISIDs that are not part of the SPBM network or region. This allows SPBM networks to interface
to other PBB networks that use other control planes. Static MACs allow remote PBB Epipes to
have connectivity to SPBM. Static ISIDs allow I-VPLS services to connect to non SPBM I-
41
VPLS services. Optionally, an ISID policy can be defined to use the default multicast tree and
to suppress the advertisement of ISIDs in SPBM when I-VPLS or static ISIDs are used for
unicast services.
This feature is supported on spoke-SDPs with active/standby pseudowires and SAPs on MCLAG.
Inter-AS Option C
for mVPN
Inter-AS mVPN allows for the set-up of Multicast Distribution Trees (MDTs) that span multiple
Autonomous Systems (ASes). Release 11.0.R4 adds Inter-AS Option C support for mVPN,
which allows operators to improve upon the Inter-AS mVPN Option A/B scalability through
exchange of Inter-AS routing information. Inter-AS Option C is typically deployed when a
common management exists across all ASes involved in the Inter-AS mVPN. Inter-AS mVPN
Option C is supported for PIM SSM with Draft-Rosen mVPN using MDT SAFI and PIM RPF
vector.
PW SAP for
IES/VPRN
Services
PW SAPs provide the ability to apply access QoS policies to a pseudowire at an MPLS networkfacing port. Release 10.0.R4 introduced the support for enhanced subscriber management on
pseudowires using PW SAPs. Release 11.0.R4 extends this feature to support non-subscriber
SAPs on IES and VPRN interfaces. PW SAPs are only supported on Ethernet ports, and the port
must be in hybrid mode. As in the ESM case, they may be associated with a whole PW (NULL)
or a specific s-tag or s-tag and c-tag combination. PW SAPs use PW ports, which support TLDP PW status signaling, as well as active/standby dual-homing into redundant PE nodes. All
of the PW SAPs bound to a PW port may be rate-limited as an aggregate using Vport shapers
or exp-secondary-shaper, as well as ingress and egress QoS policies, including redirection to
access ingress or egress queue groups.
PW SAPs for IES/VPRN interfaces are configured using the following new command:
config>service> ies|vprn service-id [customer customer-id][vpn vpn-id] interface interfacename sap pw-pw-sap-id[:[s-tag[.c-tag]]]
This feature also introduces a new config>service>sdp>binding>pw-port>egress>shaper CLI
node, and deprecates the existing shaping command under the pw-port>egress context.
A Vport with port-scheduler at the physical port does not support a distributed-mode LAG in
Release 11.0, even though CLI does not block the configuration.
CSC IP VPN
Enhancements
42
Release 11.0.R4 enhances the Carrier-Serving-Carrier (CSC) VPN functionality. The following
new capabilities are available on an SR OS router deployed as a CSC-PE:
The support for OSPFv2 as an IPv4 routing protocol between the CSC-PE and the CSC-CE
The ability to configure the CSC-CE as a (directly-connected) iBGP peer of the CSC-PE,
supporting the exchange of labeled-IPv4 routes
The ability to configure the CSC VPRN as a BGP route reflector, with some/all of the
CSC-CE iBGP peers configured as clients. In this configuration, the CSC VPRN can set
next-hop-self so that it acts as an MPLS LSR between CSC-CE routers
The support for PIM and Draft-Rosen mVPN by CSC VPRNs.
HTTP In-Browser
Notification
Release 11.0.R4 introduces AA-ISA HTTP in-browser notification which enables the operator
to send in-browser notification messages to their subscribers. The notification format can either
be an overlay, a web banner, or a splash page that makes HTTP notification less disruptive than
standard HTTP redirection for the subscriber; both the original content and the notification
message can be displayed at the same time while browsing. This capability is enabled by
configuring an HTTP-Notification policy for an AA Group, and invoking this policy using a
new AQP action http-notification.
Release 11.0.R4 also introduces a new RADIUS Alc-AA-Sub-Http-Url-Param VSA that can
be used by the operator to customize the notification messages.
AA ICAP URL
Filtering
Release 11.0.R4 introduces the Internet Content Adaptation Protocol (ICAP) URL filtering
feature, which provides a cost-effective network-based content filtering solution to the
operators for parental control and category-based URL-filtering services in broadband, mobile
and business VPN networks. This solution utilizes offline web-filtering servers over the ICAP.
The AA-ISA ICAP Client extracts the URL from the subscriber's HTTP/HTTPS request and
sends ICAP rating requests to the ICAP server (web filter) along with the subscriber-id
information. The ICAP server can then return an accept or redirect response based on various
criteria such as subscriber profile, URL categories, whitelist, blacklist, time of the day, etc.
AA 6RD Support
Release 11.0.R4 supports AA services (application detection, reporting and control) on traffic
encapsulated within 6RD tunnels.
Online Certificate
Status Protocol
(OCSP)
The Online Certificate Status Protocol (OCSP) enables applications to determine the
(revocation) state of an identified certificate. Unlike Certificate Revocation List (CRL), which
relies on checking against a periodic updated file, OCSP provides timely information regarding
the revocation status of a certificate.
In Release 11.0.R4, IPsec is the only supported application to use OCSP. The OCSP server
cannot be reached via the management routing instance.
Cflowd Support for

Ethernet Flows
In Release 11.0.R4, Cflowd support has been extended to allow for the sampling of Layer-2
traffic associated with an Epipe or VPLS service. Flow sampling is supported on ingress of
Ethernet-based SAPs. The export of Layer-2 flow information is only supported for a v10
collector configured to send the new L2-IP template through the use of the command templateset l2-ip.

SFM-X20-B
Release 11.0.R3 introduces SFM-X20-B, a new variant of SFM-X20 for 7950 XRS-20.
43
4-port 100GE CXP

XMA
400G full-duplex XMA cards are supported on 7950 XRS-20 starting with Release 11.0.R3.
The 4-port 100GE XMA is one of the two variants of the 400G XMAs driven by the fullyprogrammable FP3. It is available in either an LSR-only feature set or an IPcore feature set. The
4-port 100GE XMA offers four (4) CXP ports, compatible with Alcatel-Lucent-sourced CXP
optic modules (not included).
40-port 10GE SFP+

XMA
The second variant of the 400G XMA is the 40-port 10GE XMA. The 40-port 10GE XMA for
7950 XRS-20 is available in either an LSR-only feature set or an IPcore feature set. The 40-port
10GE XMA offers 40 SFP+ ports, compatible with Alcatel-Lucent-sourced SFP+ optic
modules (not included).
Transactional
Configuration
Transactional configuration allows an operator to edit a candidate configuration (a set of

configuration changes) in CLI without actually causing operational changes in the router (the
active or operational configuration). Once the candidate configuration is complete, the operator
can explicitly commit the changes and cause the entire new configuration to become active. A
new set of commands is provided for this functionality under the global candidate command.
Many candidate commands are only visible once the operator is in edit-cfg mode (by typing
candidate edit).
DHCPv4 OnDemand Subnet

Assignment
On-Demand Subnet Assignment (ODSA) allows multiple Broadband Network Gateways

(BNG) to share a DHCPv4 subnet pool on an SR OS-based DHCPv4 server. ODSA should be
used in conjunction with user-gi-address scope pool. ODSA is built for networks where the
subscriber population is very dynamic; subnets previously used for a BNG that now have a
lower subscriber density are automatically transferred to other BNGs with a higher demand. No
single BNG can hold up unused subnets.
In an SR OS-based DHCPv4 server, subnets within a pool can be bound to one of the following
combinations of Option 82 vendor-specific options inserted by the BNG DHCPv4 relay agent
in DHCPv4 discover/request messages: system-id, system-id + service-id, or string.
For example, with system-id as the subnet-binding key, the first DHCPv4 discovery from a
BNG binds a subnet within the pool to the BNG's system-id and an address from that subnet is
offered. For subsequent DHCPv4 discoveries from the same BNG (same system-id), addresses
from the bound subnet are offered. DHCPv4 discoveries from another BNG (different systemid) binds to a new subnet and addresses from the new bound subnet are offered. Multiple subnets
can be bound to the same BNG (system-id) as their subscriber base grows. When a subscriber
disconnects from the BNG, the address is released back to the server. If the last lease of a bound
subnet is released, then the subnet is unbound and becomes available for binding to another
BNG after a configurable unbind-delay. The unbind-delay allows routers to withdraw the
unbound subnet from the routing tables before it is used by another BNG elsewhere in the
network. ODSA is supported in a local/remote redundant DHCPv4 server configuration.

There are no new major features in 11.0.R2. See page 121 for a list of Enhancements in 11.0.R2
and page 274 for a list of Resolved Issues in 11.0.R2.
44

The following section describes the new features added since Release 10.0.R1 to
-
Hardware on page 45
System on page 50
Services on page 53
TPSDA on page 56
Quality of Service on page 73
Routing on page 75
MPLS on page 82
Application Assurance Services on page 87
OAM on page 88
Hardware
The following sections describe the new hardware supported in Release 11.0.R1.
WAN-PHY Support
for 7750 SR 12port 10G IMM, 20port 10G IMM, 1port 100G + 10port 10G IMM
In Release 10.0.R4 and higher, WAN-PHY mode support (including user-configurable signal
labels) has been added to the 12-port 10G SFP+ Multicore IMM, 20-port 10GE SFP+ Multicore
IMM and 1-port 100G CFP + 10-port 10G SFP+ IMM (added in Release 10.0.R10) as follows:
12-port 10G SFP+ Multicore IMM is enabled in groups of four (4) ports: ports 1-4, 5-8,
and 9-12
20-port 10GE SFP+ Multicore IMM is enabled in groups of four (4) ports: ports 1-4, 5-8,
9-12, 13-16 and 17-20
1-port 100G CFP + 10-port 10G SFP+ IMM is enabled in two groups of four (4) 10G ports
and one group of two (2) 10G ports: ports 1-4, 5-8 and 9-10
All ports in a group must be shut down before the WAN/LAN mode can be changed.
1-port 100G
integrated tunable
DWDM MultiCore
IMM
Release 11.0.R1 introduces the support for a new FP3-based Multicore-CPU IMM. The 1-port
100Gbps integrated tunable DWDM MultiCore IMM supports Ethernet inside OTU-4 framing
and data rate. The feature set is aligned to the currently available 10GE tunable MDA and 40G
OTU-3 tunable IMM for a comprehensive portfolio and solution.
Modulation: Coherent 100Gbps polarization multiplexed-quadrate phase shift keying (PMQPSK)
Software selectable wavelength tunable across 89 DWDM channels (50Ghz spacing)
Feature alignment with 10G and 40G Serial MDA/IMMs
Enhanced FEC (EFEC)
45
Long-haul applications: EFEC provides additional coding gain to extend optical transport
distances up to 3000km (native reach to 80km)
Ethernet inside OTU-4 framing and data rate
Full C band 89 channels: 1528.773nm/196.1 THz to 1563.86nm/191.7 THz
Innovative Alcatel-Lucent Wavelength Tracker functionality
Enables end-to-end tracking and adjustment of optical power/signal amplitude
ITU-T G.709 OAM support
Alarm indication signal (AIS), forward defect indication (FDI), open connection indication
(OCI) and payload missing indication (PMI)
Soft Reset support
Supported in 7750 SR-7/12/12e and 7450 ESS-7/12 chassis equipped with SF/CPM4 only.
license(s).
1-port 100GE CFP
+ 10-port 10GE
SFP+ MultiCoreCPU-based IMM
Release 11.0.R1 introduces the 1-port 100GE CFP + 10-port 10GE SFP+ MultiCore-CPUbased IMM to the Alcatel-Lucents IMM family. The 1-port 100GE CFP + 10-port 10GE SFP+
IMM uses the FP3 chipset, providing 200G of bandwidth in the IMM form factor.
128K queues flexibly configurable to any/all ports for ingress and/or egress
Supports 200Gbps throughput when two (2) SF/CPM4s are installed/operational in a 7750
SR-7/12 and 7450 ESS-7/12 chassis. Supports 200Gbps throughput in a 7750 SR-12e
chassis when at least three (3) SFM modules are installed/operational
that aligns with the earliest generation of IOMs installed in the chassis)
IOM3-XPs and IMMs
Support for Alcatel-Lucent-sourced CFPs and SFP+ optic modules (not included)
Power and cooling: an upgrade to PEM-3 and to the latest Enhanced Fan Tray is required
for systems utilizing these IMMs
Soft Reset support
Supported in the 7750 SR-7/12 and 7450 ESS-7/12 equipped with SF/CPM4 only, and in
the 7750 SR-12e
license(s).
46
7950 XRS-20
The Alcatel-Lucent 7950 eXtensible Routing System (XRS) core router, introduced in Release
10.0.R4, delivers scale, efficiency and versatility on a single platform without sacrificing
flexibility. This enables service providers to meet core routing, MPLS switching, datacenter
interconnection and infrastructure service needs in metro cores and IP backbones. The system
is based on the innovative and flexible FP family of network processors providing the highest
performance even when configured to provide complex services. The system runs on the
proven, resilient, and feature-rich SR OS operating system which supports a full range of core
networking. All of this is delivered on a single platform that combines industry leading capacity,
versatility, and efficiency without compromise.
The 7950 XRS-20 supports:
WAN-PHY Support
for 7950 XRS 20port 10G C-XMA
MS-ISA on 7450
Mixed-Mode
N+1 redundant power
1+1 redundant fans
1+1 redundant CPMs (Control and Processing Modules)
1+1 redundant front panel CCMs (Chassis Control Modules)
7+1 redundant SFMs (Switch Fabric Modules)
Hot-swappable system components and physical interfaces
In Release 10.0.R6 and higher, WAN-PHY mode support (including user-configurable signal
labels) has been added to the 20-port 10GE SFP+ C-XMA on the CX20-10G-SFP card and is
enabled in groups of four (4) ports: ports 1-4, 5-8, 9-12, 13-16 and 17-20. All ports in a group
must be shut down before the WAN/LAN mode can be changed.
In Release 11.0.R1, the following are now supported on the MS-ISA on the 7450 ESS in mixedmode:
IPsec
NAT
FCC/RET
CPM-X20
CPM-X20 is the first generation Control Processing Module for the 7950 XRS-20 platform
supported by Releases 10.0.R4 and higher. This high-powered CPM houses two (2) separate
CPU complexes ensuring a highly-scalable routing and control plane for the 7950 XRS-20.
Each CPM-X20 hosts two (2) MultiCore CPUs and their associated memory (8 GB DRAM per
CPU). The CPM-X20 is fully redundant and hot-swappable.
SFM-X20
SFM-X20 is a multi-purpose Switch Fabric Module for the 7950 XRS-20 platform supported
by Releases 10.0.R4 and higher. Eight (8) of these Switch Fabric Modules are used in parallel
in a 7+1 redundant switching architecture to deliver a total of 16Tbps (half duplex) switching
capacity in a single 7950 XRS-20 system. The SFM-X20 is fully redundant and hot-swappable.
CCM-X20
The Chassis Control Module (CCM) provides a front-of-rack, two-way communication

instrument for operational personnel who interface with the 7950 XRS-20 system supported by
Releases 10.0.R4 and higher. Two CCMs are installed in each 7950 XRS-20, each having an
association with one of the two CPMs in the system. The CCMs, redundant and hot-swappable,
provide the following interfaces: one (1) RJ-45 Ethernet Out-of-Band (OOB) Management port,
47
one (1) RJ-45 BITS ports, one (1) RJ-45 serial OOB console port (with DTE/DCE switch), three
(3) terminal-style alarm relay contacts, one (1) ACO/LT button, two (2) removable compact
flash slots, and one (1) embedded 100-GB solid state hard drive.
XCM-X20
The XMA Control Module (XCM) is a full-height I/O Module that provides Switch Fabric Tap
access and the slot-level control plane functions for the 7950 XRS-20 system introduced in
Release 10.0.R4. Each XCM-X20 provides two (2) 400 Gbps (full duplex) Fabric Taps (one per
XMA slot) providing 800 Gbps full duplex. The XCM-X20 also provides a MultiCore CPU and
4 GB of DRAM in support of slot-level control plane functions. Up to ten (10) XCM-X20
modules, which are hot-swappable, can be installed in a 7950 XRS-20 chassis.
2-port 100GE CFP

C-XMA
One of two separate variants of 7950 XRS line cards supported by Releases 10.0.R4 and higher,
called C-XMAs, perform all PHY- and MAC-layer functions as well as housing the FP3
forwarding complex.
The 2-port 100GE C-XMA for 7950 XRS is available in either an LSR-only feature set or in a
separately orderable IP-Core feature set variant. The 2-port 100GE C-XMA offers two CFP
ports, compatible with all Alcatel-Lucent family of CFP modules (CFPs not included).
20-port 10GE SFP+

C-XMA
The 20-port 10GE C-XMA for 7950 XRS is available in either an LSR-only feature set or in a
separately orderable IP-Core feature set variant. The 20-port 10GE C-XMA offers 20 SFP+
ports, compatible with Alcatel-Lucent-sourced SFP+ optic modules (not included).
7750 SR-12e
7750 SR-12e, supported since Release 10.0.R5, is the latest addition to the 7750 Service Router
family, supporting up to 3.6Tbps (half duplex) of overall bandwidth while providing full service
router capabilities. The 7750 SR-12e has been designed to deliver differentiated, highperformance, high-availability services and supports specialized service-aware application
processing, advanced quality of service (QoS), and a comprehensive range of Ethernet and
multi-service interfaces and protocols. The 7750 SR-12e provides industry-leading scale and
intelligence to deliver residential, business, and wireless broadband IP services on a converged
edge routing platform.
The 7750 SR-12e supports:
3+1 Redundant Switch Fabrics
1+1 Redundant CPMs
9 I/O Slots
4+1 Redundant power equalizers
Redundant fan trays
All software features of the 7750 SR-12 chassis unless explicitly stated otherwise
Refer to Table 4 on page 6 for the list of IOM/IMMs supported on 7750 SR-12e.
SF/CPM4-12e
48
The SF/CPM4-12e is a combined control processing (CPM) and switch fabric (SFM) module
for SR-12e supported by Release 10.0.R5 and higher. The control processing function operates
in a 1+1 active/standby redundancy model where a pair of SF/CPM4-12e cards provide a fully
redundant and hot synchronized control plane (i.e., the CPM function). The SF/CPM4-12e
offers 8GB of control plane DRAM. The switch fabric in the 7750 SR-12e operates in a 3+1
redundancy scheme where two of the fabric elements are present on each of the SF/CPMs and
the other two are present on mini switch fabric modules (Mini-SFM). Fully redundant 200Gbps
(full duplex) per slot is delivered in a configuration with two SF/CPM4-12e modules and two
Mini-SFM4-12e modules. The SF/CPM4-12e module is hot-swappable.
Mini-SFM4-12e
Mini Switch Fabric Modules are required (along with the switch fabric function of the
SF/CPM4-12e card) to provide a fully redundant fabric for the 7750 SR-12e platform supported
by Releases 10.0.R5 and higher. The switch fabric in the 7750 SR-12e operates in a 3+1
redundancy scheme where two of the fabric elements are present on each of the SF/CPMs and
the other two are present on mini switch fabric modules (Mini-SFM). Fully redundant 200Gbps
(full duplex) per slot is delivered in a configuration with two SF/CPM4-12e modules and two
Mini-SFM4-12e modules. The Mini-SFM4-12e module is hot-swappable.
2-Port 100G, 6-Port

40GE and 20-Port
10GE MultiCoreCPU Ethernet
IMMs
Three new MultiCore-CPU-based IMMs were introduced in Release 10.0.R4: a 2-port 100GE
CFP MultiCore-CPU IMM, a 6-port 40GE QSFP MultiCore-CPU IMM and a 20-port 10GE
SFP+ MultiCore-CPU IMM. These IMMs use the new FP3 chipset, providing 200G of
bandwidth in IMM form factor (the term 200G FP3-based MultiCore-CPU IMMs used
elsewhere in the document refers to this set of IMMs being supported starting in Release
10.0.R4). These IMMs offer the following benefits:
128K queues flexibly configurable to any/all ports for either ingress and/or egress.
Supports 200Gbps throughput when two (2) SF/CPM4s are installed/operational.
A single powerful fabric tap chip that delivers single flows of 100Gbps.
that aligns with the earliest generation of IOMs installed in the chassis).
IOM3-XPs and IMMs.
Support for Alcatel-Lucent-sourced CFPs, QSFPs and SFP+ optic modules (not included).
Power and cooling: it is required to upgrade to PEM-3 and to the latest Enhanced Fan Tray
for systems utilizing these IMMs.
Supported in 7750 SR-7/12 and 7450 ESS-7/12 chassis equipped with SF/CPM4 only.
license(s).
the higher performing IOM3-XP and newer IOM/IMM modules. Note that even when only one
IMM/IOM is deployed, impedance panels are required.
In Release 11.0.R1, support has been added to Soft Reset and ESM for these IMMs.
2-Port 10GE + 12Port GE MDA-XP
Release 10.0.R4 introduced a new MDA: 2-port 10GE XFP + 12-port GE MDA-XP. The
feature set for this MDA includes:
Two (2) XFP ports (XFPs not included) and twelve (12) SFP ports (SFPs not included),
compatible with the entire family of existing Alcatel-Lucent XFP and SFP modules.
49
12-Port GE MDAXP
2-Port OC192/STM-64 MDAXP
Support for over-subscription provided through on-board prioritization logic and buffering
with the ability to prioritize based on IEEE 802.1p bits or DSCP bits
Hot insertion and hot removal for full hot-swap support
Support in hardware for synchronous Ethernet (SyncE) timing for all optical SFP/XFP
applications.
10/100/1000BASE-T auto-sensing operation is supported with TX SFP (SyncE is not

supported).
Release 10.0.R4 introduced another new MDA: 12-port GE SFP MDA-XP. This MDA supports
a host of features including:
Twelve (12) SFP (Small Form Factor Pluggable) ports (SFPs not included), compatible
with the entire family of existing Alcatel-Lucent family of SFP modules
Support for over-subscription provided through on-board prioritization logic and buffering
with the ability to prioritize based on IEEE 802.1p bits or DSCP bits
Support for non-blocking performance on all ports when used with IOM3-XP
Hot insertion and hot removal for full hot-swap support
Support in hardware for synchronous Ethernet (SyncE) timing for all optical SFP
applications
10/100/1000BASE-T auto-sensing operation is supported with TX SFP (SyncE is not

supported).
The 2-port OC-192/STM-64 XFP MDA-XP introduced with Release 10.0.R4 provides
standards-compliant encapsulation of point-to-point protocol (PPP) traffic over SONET/SDH
(POS), which enables scalable and reliable leased line services and optical transport delivery
over a converged IP/MPLS network. The 2-port OC-192/STM-64 MDA-XP offers two XFP
ports (optics sold separately). This MDA is supported on IOM3-XP only.
System
The following section describes the new system features in Release 11.0.R1.
Distributed CPU
Protection
Release 11.0.R1 supports Distributed CPU Protection (DCP). It offers a per-protocol-per-object

(examples of objects are SAPs and network interfaces) rate limiting function for control
protocol traffic that is extracted from the data path and sent to the CPM. The DCP function is
implemented on the line cards, allowing for high levels of scaling and granularity of control.
DCP is supported on FP2- or higher-based line cards.
SyncE on Copper
Copper Ethernet ports now support transmit timing locked to the nodes central clock starting
with Release 11.0.R1. These ports can also be configured to receive timing from the line and
then be available as an input reference to the central clock of the SR/ESS. ESMC message
processing is also supported on these ports.
50
This capability is new in Release 11.0.R1 for the following assemblies and only in 100BASETX and 1000BASE-T modes. It is not supported on ports in 10BASE-T mode.
TABLE 11. SyncE Supported Assemblies
Part Number
Description
3HE05160AA
7750 SR 48-port 10/100/1000 - XP MDA - mini-RJ21
3HE05159AA
7450 ESS 48-port 10/100/1000 - XP MDA - mini-RJ21
IPv4 Address
Prefix List Match
Criterion for CPM
IP Filter Policy
Release 10.0.R4 introduced support for IPv4 address prefix list for CPM IP filter policy. Please
see the new feature description in the Routing subsection of this document for more details.
IPv6 address
prefix list match
criterion for CPM
IPv6 filter policy
Release 11.0.R1 introduces support for IPv6 address prefix list for CPM IPv6 filter policy. See
the new feature description in the Routing subsection of this document for more details.
Auto-generation of
filter-policy match
criteria for CPM
policies
Release 11.0.R1 introduces a capability to auto-generate address prefixes inside IPv4 and IPv6
address prefix match lists. When an operator creates filter policies that use address prefix match
list with a configured auto-generation of address prefixes, the filter policy entries match criteria
are automatically updated when the routers configuration matching the configured address
prefix auto-generation rules changes. This functionality allows for a touch-less CPM filter
policy management.
Release 11.0.R1 allows operators to auto-generate IP and IPv6 address prefix match lists
entries based on BGP peer configuration and to use those match lists in CPM filter policies.
When BGP configuration changes, the match list(s) are auto-populated with the BGP neighbor
address prefixes changes and, in turn, filter policies that use those match lists are updated as
required.
Increased APS
group scaling
Release 11.0.R1 introduces increased single-chassis and multi-chassis scaling for APS groups
on 7750 SR-7/12/12e and 7450 ESS-7/12. The increase scaling is targeted for higher scale
aggregations networks, especially mobile backhaul.
Per-Link Hashing
Release 11.0.R1 supports per-link hashing, which ensures that all egress data traffic on a LAGbased SAP or network interface will use a single physical port of that LAG. All SAPs/network
interfaces are sprayed across all active LAG ports while ensuring that traffic for each SAP or
network interface egresses over a single LAG port. All egress traffic is automatically rehashed
when a LAG port goes down or a LAG port comes up. Release 11.0.R1 supports per-linkhashing only for LAG-based L3 IES/VPRN SAPs or network interfaces, excluding ng-mVPN
multicast.
51
LAG Link Mapping

Profiles
Release 11.0.R1 supports LAG link mapping profile, which gives operators full control of
which LAG member traffic egressing on SAPs/network interfaces will be using and how that
traffic is re-hashed on a LAG port failure. Some benefits that such functionality provides
include:
The ability to perform management level admission control onto LAG ports, thus
increasing overall LAG bandwidth utilization and controlling LAG behavior on a port
failure
The ability to strictly enforce a QoS contract on egress for a SAP/network interface or a
group of SAPs/network interfaces by forcing it/them to egress over a single physical port.
To enable the LAG link mapping profile feature on a given LAG, operators configure one or
more of the available LAG link mapping profiles on the LAG, and then assign that profile(s) to
all or a subset of SAPs and network interfaces as needed. Each LAG link mapping profile
specifies primary and secondary egress ports to be used by a SAP/network interface on the given
LAG and a failure mode to use when both primary and secondary ports are not available.
IPv6 Support for
IES/VPRN MLPPP
Interfaces
Release 10.0.R4 and higher support IPv6 traffic on IES/VPRN interfaces configured with LFI,
MLPPP, MLPPP-MC bundles and bundle protection groups on the ASAP MDA family.
IEEE 1588
Boundary Clock
The IEEE 1588 capabilities in the SR/ESS were enhanced in Release 10.0.R4 and higher to
support boundary clock functionality. This allows the SR/ESS to be used as part of a chain of
IEEE 1588 clocks delivering frequency and/or time synchronization from the source node
(Grandmaster) through the network of boundary clocks to the edge slave devices. The use of
boundary clocks segments the end-to-end packet delay variation into smaller spans that can be
filtered more easily. Boundary clocks also allow for fanout across the network both reducing
the bandwidth requirements and providing greater scaling.
IEEE 1588 Boundary Clock is supported on the following platforms:
IEEE 1588 Default

Profile
1588 Port-Based
Timestamping
52
7750 SR-12 with SF/CPM3 or higher (requires PCN: C04765)
7750 SR-7 with SF/CPM3 or higher (requires PCN: C04765)
7750 SR-c4
7450 ESS-7 with SF/CPM3 or higher (requires PCN: C04765)
7450 ESS-12 with SF/CPM3 or higher (requires PCN: C04765)
The support for the default profile of the IEEE 1588-2008 standard was added in Release
10.0.R4. The transport plane uses UDP/IPv4 and negotiated unicast sessions for inter-clock
communications. The clock topology is managed using the Best Master Clock Algorithm
defined in the standard.
The PTP Boundary Clock implementation in the SR/ESS supports the distribution of high
accuracy time starting with Release 11.0.R1. This allows the SR/ESS to be used as part of a
chain of PTP clocks starting from a GNSS receiver-based Grandmaster and ending with an end
Slave clock.
The highest accuracy is achieved when the PTP packets are processed at the port level using
PTP port-based timestamping. This capability is enabled on an IP interface and applies to
interfaces associated with ports on the following hardware assemblies. PTP port-based
timestamping is only supported on 7750 SR-7/12 and 7450 ESS-7/12 with SF/CPM3 or higher.
TABLE 12. PTP Port-Based Timestamping Supported IMMs and MDAs
Part Number
Description
3HE03622AA
3HE03623AA
3HE05899AA
3HE05899BA
3HE06431AA
3HE03611AA
3HE03612AA
3HE03612AA
7750 SR 2-port 10GBASE - XP XFP MDA
3HE03686AA
3HE04274AA
3HE03614AA
3HE03615AA
7450 ESS 20-port GE - XP - SFP MDAa
3HE03687AA
7450 ESS 2-port 10GBASE - XP XFP MDA
3HE03688AA
7450 ESS 4-port 10GBASE - XP XFP MDA
3HE04273AA
7450 1-port 10GBASE - XP XFP MDA
a. Capability available on ports one (1) through 11 inclusive.
The MDAs must reside in one of the following IOMs to allow for PTP port-based timestamping:
TABLE 13. PTP Port-Based Timestamping Supported IOMs
Part Number
Description
3HE06318AA
3HE06324AA
3HE03619AA
3HE03620AA
7450 ESS IOM3-XP (iom3-xp)
Services
The following sections describe the new services features in Release 11.0.R1.
Ipipe for 7950 XRS
Ipipe service capability has now been added to the 7950 XRS platform with Release 11.0.R1.
Ipipe VLL service enables IP service interworking between different link layer technologies
such as FR, ATM, PPP and Ethernet (note that FR, ATM and PPP SAPs are not supported on
53
the 7950 XRS platform but could exist at the other end of the Ipipe on a 7750 SR-12, for
example). An Ipipe VLL can also be used to configure a spoke interface into an IES or VPRN
service.
G.8031 Protected
Ethernet Tunnel
support for 7950
XRS
The 7950 XRS now supports ITU-T G.8031 specification compliance to achieve 50ms
resiliency for failures in a native Ethernet backbone for native Layer 2 networks.
mVPN Senderonly/Receiver-only
In mVPN, by default, when multiple PE nodes form a peering within a common mVPN
instance, each PE node originates a multicast tree locally towards the remaining PE nodes that
are member of this mVPN instance. This behavior creates a mesh of I-PMSI across all PE nodes
in the mVPN. In Release 11.0.R1, mVPN Sender-only/Receiver-only allows operators to
optimize core control-plane and data-plane resources when a given PE hosts multicast sources
only, or multicast receivers only.
IPv6 ng-mVPN
Multicast support
Release 11.0.R1 provides the support for operators to offer customers IPv6 mVPN service. An
operator utilizes an IPv4 core to carry IPv6 customer-multicast traffic inside IPv4-mLDP or
-RSVP-TE provider tunnels (p-tunnels). The IPv6 customer-multicast on a given mVPN can be
blocked, enabled on its own or in addition to IPv4 multicast per PE or per interface. When both
IPv4 and IPv6 multicast is enabled for a given mVPN, a single tree is used to carry both IPv6
and IPv4 traffic.
SDP
Administrative
Groups
Release 11.0.R1 introduces the support for SDP administrative groups, referred to as SDP
admin groups. SDP admin groups provide a way for services using a pseudowire template to
automatically include or exclude specific provisioned SDPs.
SDPs sharing a specific characteristic or attribute can be made members of the same admin
group. When users configure a pseudowire template, they can include and/or exclude one or
more admin groups. When the service is bound to the PW template, the SDP selection rules will
enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.
A maximum of 32 admin groups can be created. The group value ranges from zero (0) to 31. It
is uniquely associated with the group name at creation time. If the user attempts to configure
another group name for a group value that is already assigned to an existing group name, the
SDP admin group creation will fail. This is also true if the user attempts to configure an SDP
admin group with a new name, but associates it to a group value already assigned to an existing
group name.
SDP admin groups can be enabled on all SR OS services that make use of the pseudowire
template (i.e., BGP-AD VPLS service, BGP-VPLS service, and FEC129 VLL service). For the
FEC129 VLL service, this feature provides the support at the T-PE nodes only. Signaling of the
admin group constraint in the spoke-sdp-fec is not supported.
Inverse capture
SAP
54
With Release 11.0.R1, on QinQ-encapsulated Ethernet ports, it is now possible to create an

inverse capture-SAP that matches on a fixed inner tag with the outer tag identifying the user.
The following restrictions apply when an inverse capture-SAP is configured on a port:
BGP VPWS
It is not possible to create y.* saps when there is a *.x capture SAP present on the port.
(y=0,1..4094,* and x=1..4094).
It is not possible to create a y.* network interface when there is a *.x capture SAP present
on the port (y=0,1..4094,* and x=1..4094).
Release 11.0.R1 adds the support for a BGP Virtual Private Wire Service (VPWS), which is a
point-to-point L2 VPN based on RFC 6624. This allows a virtual leased line to be created
between two systems.
BGP VPWS is configured under an Epipe service and connects a single SAP to a single BGPsignaled spoke-SDP/pseudowire, where the latter can use any available MPLS LSP tunneling
protocol.
Dual-homing is also supported using BGP multi-homing, in which case, a single pseudowire is
established between one system and the designated forwarder of the dual-homed pair. On
failover of the designated forwarder, the pseudowire would be deleted and re-established to the
new designated forwarder. VPLS preference can be used to determine to which system the
pseudowire is established as part of the VPWS update process tie-breaking rules, as described
in draft-ietf-l2vpn-vpls-multihoming-03.
Ethernet-encapsulated SAPs are supported, including LAG SAPs, but not MC-LAG. There is
no support for inter-AS services or for 802.1ag on the SAP.
Routed I-VPLS
Release 11.0.R1 supports Routed I-VPLS (R-IVPLS), which allows an I-VPLS instance to be
bound to an IES or VPRN interface. Within an R-IVPLS service, traffic ingressing on I-VPLS
SAPs/SDP-binds or B-VPLS SAPs/SDP-binds with a destination MAC matching that of the
associated IP interface will be routed based on the IP forwarding table; all other traffic will be
forwarded based on the VPLS forwarding table.
The R-IVPLS service can be associated with either an IPv4 or IPv6 interface and can run routing
protocols over the R-IVPLS service including OSPF, IS-IS, RIP and BGP (Note: BGP is
supported in 7450 ESS in mixed-mode only), and requires that all network interfaces, all SAPs
within the same routing domain as the R-IVPLS and all SAP interfaces associated with the RIVPLS and B-VPLS instance to be located on IOM3-XP or IMM cards. R-IVPLS services, in
addition to R-VPLS restrictions, do not currently support multicast routing. R-VPLS and RIVPLS are not supported on the 7950 XRS platform in this release.
Note: IES/VPRN SAPs on the SR/ESS platforms can be on non-IOM3-XP or IMM cards, but
traffic to/from them will not be forwarded by R-VPLS or R-IVPLS instances.
Epipe Oper State

Decoupling
With Release 11.0.R1, one can now configure a single SAP in an Epipe that allows the
operational state of the Epipe to remain up, even when that SAP enters a failed operational down
state. There is no indication that the service is unable to forward transit traffic when this
condition is active. This is only applicable to Epipes that exclude alternate egress points (e.g.,
MC-LAG with ICB or PBB backup tunnels, etc.). LAG SAPs are supported except when LAG
profiles are configured.
Inter-AS Option B
for mVPN
The Inter-AS mVPN feature, introduced with Release 11.0.R1, allows for the setup of Multicast
Distribution Trees (MDTs) that span multiple Autonomous Systems (ASs). Release 11.0.R1
adds Inter-AS mVPN Option B support and allows operators to improve upon the Inter-AS
55
mVPN Option A scalability while still maintaining AS isolation. Inter-AS Option B is

supported for PIM SSM with Rosen mVPN using MDT SAFI, using BGP Connector attribute,
and PIM RPF vector.
N-to-1 Mapping of
ATM VPI/VCI to
ATM PW
Release 11.0.R1 allows the mapping of many ATM cell flows, identified by their unique pair of
VPI/VCI value on a given ATM SAP, to the same ATM PW. This is performed by extending
the ATM VLL of vc-type atm-cell by adding a new SAP type which consists of a list of discrete
pairs of VPI/VCI values.
MC APS support
for ATM SAP in Nto-1 mapping of
ATM VPI/VCI to
ATM Pseudowire
Release 11.0.R1 enhances the support for ATM pseudowire Apipe services by adding the
support for multi-chassis APS. An ATM SAP with a connection profile allowing N-to-1
mapping of ATM VPI/VCI to ATM pseudowire as part of the Apipe service can now be
configured on a MC-APS-protected port.
PW Shaping for L2
and L3 Services
The ingress and egress pseudowire (PW) shaping features are extended to support Ipipe, Fpipe,
Apipe, and Cpipe VLL services, starting with Release 10.0.R4.
B-VPLS Shortest
Path Bridging
(SPB)
Shortest Path Bridging (SPB 802.1aq), added to SR OS in Release 10.0.R4, enables a next
generation control plane for PBB based on IS-IS that adds the stability and efficiency of a link
state protocol to unicast and multicast services. Release 10.0.R4 supports the SPBM (SPB MAC
mode) version of that new control plane. PBB B-VPLS is deployed currently in both Ethernet
and MPLS networks supporting point-to-point and multipoint-to-multipoint services with large
scale services (Ethernet VLL and VPLS). SPB removes the flooding and learning mode from
the PBB backbone network. It can also replace MMRP for ISID Group MAC Registration to
provide flood containment. SR OS SPB provides the ability to create true shortest-path
forwarding tree topology for unicast and efficient single-tree forwarding tree topology for
multicast. SPB offers equal-cost tie-breaking algorithm to enable diverse forwarding in the
network. This feature is available on the 7950 XRS, 7750 SR-c4/c12, 7750 SR-7/12 and 7450
ESS-6/6v/7/12, and requires FP2- or higher-based line cards.
TPSDA
The following features are new to the Triple Play Service Delivery Architecture (TPSDA) in
Release 11.0.R1.
ESM SUPPORT ON
FP3-based IMMs
NAT Support for
10x MSISA/chassis
56
In Release 11.0.R1, Enhanced Subscriber Management (ESM) is supported on all FP3-based

Multicore-CPU IMMs.
In Release 11.0.R1, up to ten (10) active MS-ISAs are supported for NAT per system with any
number of additional MS-ISAs configured as standby.
PPPoE/IPoE
Session Setup
Performance
The setup rate for PPPoE/IPoE hosts has been improved, starting with Release 11.0.R1.
Open
Authentication
Model
In addition to IPv4 hosts (DHCPv4 and PPPoEv4), the Local User Database (LUDB) access
under the capture SAP is now available for IPv6 hosts (DHCPv6 and PPPoEv6) in Release
11.0.R1.
Parameters needed for subscriber-host instantiation can be retrieved from a mix of sources in
the following order of priority:
LUDB
RADIUS
Via a DHCP option specified in sub-ident-policy. This option is extracted during ACK
processing.
Python scripting on DHCP ACK
Statically configured defaults
The IP address assignment model remains the same:
DHCP Proxy a specific IP address/prefix is assigned to the host directly via LUDB or
RADIUS.
DHCP Relay IP address/prefix is assigned to the host via a DHCP pool on the internal or
external DHCP server. The pool name can be obtained via LUDB or RADIUS.
The parameters that can be obtained via LUDB (with or without RADIUS) during the host
instantiation phase are the following:
MSAP-defaults (service id, msap-policy and group-interface).
Retail service ID in Wholesale/Retail VPRN model.
Identification strings (ancp-string, app-profile-string, category-map-name, inter-dest-id,

sla-profile-string, sub-profile-string and subscriber-id).
IP addressing information:
-
IPv4 pool name (in case of DHCP relay)
IPv4 address (in case of DHCP proxy)
IPv6 IA-NA address (in case of DHCP proxy)
IPv6 IA-PD prefix (in case of DHCP proxy)
IPv6 IA-NA DHCP pool name (in case of DHCP relay)
IPv6 Delegated prefix DHCP pool name (in case of DHCP relay)
IPv6 Delegated prefix length (in case of DHCP relay)
IPv6 SLAAC Prefix (in case of DHCP proxy)
Authentication domain name for username manipulation before accessing RADIUS (IPoE
only). Note that username manipulation for PPPoE hosts is performed via authenticationpolicy.
Certain configurable DHCPv4 options (in case of DHCP proxy only).
Certain configurable DHCPv6 options (in case of DHCP proxy only).
Accounting policy in case that the host instantiation fails and an acct-stop message must to
be generated.
57
DHCPv4 server IP address. Note that this server IP address must also be configured under
the configure>service>vprn/ies>sub-if>grp-if>dhcp# hierarchy as part of a group of
DHCPv4 server IP addresses.
Wpp-policy (IPoE only)
Access-loop-encapsulation (MLPPP only)
Access-loop-information (PPPoE Only)
Interface (LNS only)
L2TP group
Pre authentication policy (PPPoE only). For PPPoE clients, it is allowed to have two
consecutive accesses to RADIUS server from LUDB. One use case for this would be to
retrieve certain parameter(s) (for example, LLID Logical Line Identifier) from the first
RADIUS access and then reflect this parameter back to the RADIUS in the second
RADIUS access.
In addition, the following actions via LUDB access are supported:
Force-ipv6cp (PPPoE only)
Pado-delay (PPPoE only)
When IP addressing parameters (pool name and IP address) are received simultaneously from
two different sources (LUDB and RADIUS), the proxy addressing (specific IP address) will
take precedence over DHCP relay (pool name).
When the default-sub-id is changed for an existing subscriber, only the new hosts will be
affected by this change.
ESM LAG Hashing
per Vport
Vport is an SR OS BNG representation of a remote traffic aggregation point in the access

network that requires QoS treatment. In other words, Vport is a level in the hierarchical QoS
model implemented within the SR OS BNG.
In cases where the SR OS BNG is connected to an access network via a LAG, a Vport construct
within the BNG in Release 10.0.R5 and higher can be instantiated per member link on that LAG.
Each instance of the Vport in such a configuration receives the entire amount of configured
bandwidth. Spraying subscriber traffic over member links in a LAG without awareness of the
Vport could have led to packet drops on one member link irrespective of the relative traffic
priority on another LAG member link in the same Vport. The reason was that multiple Vport
instances of the same Vport on different LAG member links were not aware of each other. To
remedy this situation, all traffic flowing through the same Vport will now be hashed to a single
LAG member link. Traffic treatment will be controlled by a single Vport instance.
This feature requires that all active member ports in a LAG reside on the same
IOM/IMM/XCM. This feature is only supported on the 7950 XRS, FP2- and higher-based line
cards on the 7750 SR/7450 ESS platforms, and 7750 SR-c4/c12.
PPPoE host with

antispoofing
improvement
58
In releases prior to Release 11.0.R1, a PPPoE host with antispoofing set to <mac, session-id, IP
address> would count as two (2) towards the IOM/system host scaling limits. In Release
11.0.R1, this has been changed so that such hosts count as one (1) towards the scaling limit.
Flexible Delegated
Prefix Length
Starting with Release 11.0.R1, it is no longer mandatory that all subscriber hosts with DHCPv6
IA-PD under the same subscriber-interface share the same delegated prefix length (statically
configured under the subscriber-interface>IPv6 hierarchy). Instead, each subscriber-host under
the same subscriber-interface can have a delegated prefix of any length between 48 and 64 bits.
The delegated prefix length can be supplied at the time of the host initiation via LUDB,
RADIUS or DHCP server.
Flexible
SubscriberInterface
Addressing for
IPoE v4/v6
IPv4/v6 address delegation to DHCP/SLAAC subscriber-hosts under the subscriber-interface is

no longer restrained to the subnets/prefixes that are configured under the subscriber-interface,
starting with Release 11.0.R1. Furthermore, it is no longer required that a subscriber-interface
have an IP address/prefix configured (unnumbered subscriber-interface) for DHCP/SLAAC
subscriber-hosts.
The default-gw IP address and/or the subnet mask will be auto-generated within and relayed to
the clients in case that only the IP address is supplied by the addressing authority (LUDB,
RADIUS, DHCP server). However, default-gw auto-generation is only supported in RoutedCO CPEs.
Since the IP address is no longer mandatory under the subscriber-interface, the gi-address can
be selected from any operational interface within the given routing context.
Tunnel Selection
Improvement on
LAC
Starting in Release 11.0.R1, the blacklist functionality on the LAC has been extended from
supporting only L2TP peers to supporting L2TP tunnels. The tunnels can be placed into the
blacklist in case of tunnel/session initialization process failures. Whether to place a tunnel into
a blacklist or not is controlled via configuration (CLI). Similarly, most triggers that will force a
tunnel into the blacklist during the tunnel/session initialization failure are controllable via
configuration. Once the tunnel or the session is established, no events other than the timeout can
force the peer into the blacklist (and therefore implicitly render the tunnel unavailable). While
the tunnel is in the blacklist, it will not be used to serve new L2TP session requests unless there
are no alternative tunnel specs available.
The following functionality related to blacklists is now supported:
Probing a blacklisted tunnel with a single (new) L2TP session initialization request
Once the session is established, the consecutive session may start using this tunnel. The
tunnel becomes eligible for probing only after its time within the blacklist has expired.
Tunnel probing can be enabled via configuration.
Configurable blacklist timer Control the amount of time an item stays in the blacklist.
Displaying the contents of the blacklist.
Manual purging of entities within the blacklist.
Generation of a log and SNMP trap when the blacklist is full.
In addition, the new tunnel selection mechanism, triggered by the L2TP session initialization
failure, can now be controlled via configuration:
all tunnels within the same preference level will be tried before the tunnel selection
mechanism moves to the next preference level.
only one tunnel within the preference level will be tried before the selection mechanism
moves to the next preference level.
59
CDN Result Code

Overwrite on LNS
Inter WLAN-GW
Redundancy and
Mobility
In Release 11.0.R1, certain Result Codes in L2TP Call-Disconnect-Notify (CDN) messages can
be overwritten in the LNS just before they are sent to the LAC. The overwrite is configurable
and it allows the following Result Codes:
4Call failed due to lack of appropriate facilities being available (temporary condition)
5 Call failed due to lack of appropriate facilities being available (permanent condition)
6 Invalid destination to be overwritten by the Result Code 2 - Call disconnected for the
reason indicated in error code.
Release 11.0.R1 implements creation of an ESM host based on authentication triggered by a

received data packet on the MS-ISA. The application of the feature provides the support for
stateless N:1 redundancy for WLAN-GW using the same inside IP address for all subscribers
with L2-aware NAT. If a WiFi AP detects failure of the primary WLAN-GW (based on periodic
pings for liveness detection of the soft-GRE endpoint), it can tunnel traffic to a configured
backup soft-GRE endpoint. This forces the traffic to be received on the backup WLAN-GW.
The IP address of the subscriber stays the same (due to L2-aware NAT). The backup WLANGW receives traffic on the MS-ISA, and based on the configuration, triggers RADIUS
authentication from the MS-ISA of the MAC and IP address received in the packet. Successful
authentication results in the ESM host creation. Based on access-accept, if the subscriber
session is determined as one that needs to be anchored on PGW/GGSN, then GTP tunnel is
signaled with the handover indication bit set. If RADIUS proxy is enabled on the backup
WLAN-GW, the data triggered authentication will result in a RADIUS proxy cache entry being
instantiated, such that subsequent re-authentications can be efficiently handled.
The subscriber traffic can be received on a WLAN-GW without prior subscriber state due to
mobility when a UE moves from one AP to the other with same SSID, such that the target AP
is anchored on a different WLAN-GW than the source AP. This scenario is supported via L2aware NAT and subscriber creation via data triggered authentication as described above.
Migrant user
support on WLANGW
60
Release 11.0.R1 adds the support to create an ESM host for a WiFi subscriber only after it has
been fully portal-authenticated or EAP-authenticated. The behavior for portal authentication,
prior to this feature, was to create an ESM host for a WiFi subscriber as soon as DHCP lease
was assigned after RADIUS authorization based on the MAC address. This consumed resources
in the system for WiFi subscribers that automatically associated with an open SSID and got an
IP address via DHCP, but did not initiate or complete portal authentication (possibly due to
being migrant [i.e., moving out of the range of access-point before completing
authentication]). This limitation affected subscriber scale and performance on WLAN-GW.
Release 11.0.R1 adds the support to turn on L2-aware NAT for users prior to successful portalauthentication, and to hand out the same inside IP address (configured per soft-GRE group
interface or per VLAN range corresponding to SSID(s)) to each subscriber from the MS-ISA
via DHCP. The first L3 packet from the subscriber triggers RADIUS authorization from the
MS-ISA based on a configured MS-ISA specific authentication policy. If a subscriber is a preauthenticated subscriber, ESM host creation is triggered based on access-accept from
RADIUS. However, if the subscriber requires portal authentication, RADIUS can send back a
reference to a redirect policy on the MS-ISA and optionally, a redirect URL (corresponding to
the login page) in access-accept. The next HTTP packet is then redirected from the MS-ISA if
it matches the term in the redirect policy. Once the user enters credentials on the login page and
is authenticated by the portal, the portal triggers a RADIUS CoA to force the creation of a
normal ESM host (without forwarding restrictions applicable to an unauthenticated user). The
ESM host, as usual, can be subjected to a NAT policy specified in the subscriber profile. The
L2-aware NAT state created prior to authentication is removed once the ESM host has been
created (potentially with a new NAT policy). Before the ESM host is created (i.e., while the user
is pending portal authentication), only packets that match the redirect policy are forwarded. This
will typically include traffic to and from the portal server(s) and traffic to and from DNS servers.
A maximum of 16 redirect policies can be created in the system, with a maximum of 64 forward
rules across all redirect policies.
Migrant user support can only be used for EAP-authentication-based closed SSIDs without
RADIUS-proxy on WLAN-GW. If no RADIUS proxy is configured on WLAN-GW, then the
initial RADIUS request carrying EAP from the AP is normally forwarded to a RADIUS server.
The RADIUS exchange is between AP and the AAA server, and no information from EAP
authentication is cached on the WLAN-GW. The subsequent DHCP DISCOVER after a
successful EAP authentication is received on the MS-ISA. If a dot1q tag is present,
determination is made based on local VLAN configuration if the subscriber is a localbreakout subscriber or a subscriber that requires to be GTP tunneled to PGW/GGSN. If the
subscriber is a GTP subscriber, then the DHCP is forwarded to the CPM, where it triggers a
RADIUS authorization. RADIUS correlates the MAC address with EAP authentication for the
user. GTP tunnel initiation (as currently supported in Release 10.0) and ESM host creation then
follow after receiving an access-accept. However, if the subscriber is a local-breakout
subscriber, then based on L2-aware NAT configuration on the MS-ISA, the same inside IP
address can be handed out to each subscriber. For local-breakout subscriber, the first L3 packet
triggers MAC-address-based RADIUS authorization from the MS-ISA. The RADIUS server
can correlate the EAP authentication with the MAC address of the user and then send an accessaccept. This triggers ESM host creation as normal.
For closed SSIDs with EAP authentication, if a RADIUS proxy function is configured on
WLAN-GW, then the initial EAP authentication from the AP is processed by the RADIUSproxy on the CPM, and is forwarded to the RADIUS server based on the configured
authentication policy. Based on the authentication response, ESM host creation with local
DHCP address assignment or GTP tunnel initiation proceeds as usual. This behavior is
unchanged from Release 10.0.
NAT dynamic port
block reservation
The outside IP address in NAT is always shared for the subscriber with a static port forward and
the dynamically allocated port block, insofar as the static port is in the range greater than 1023.
Since static port forwards do not time out on its own, in some of those cases with a shared
outside IP address, a subscriber can be starved out of the dynamic port blocks. For example,
between the last dynamic port block release and the next allocation attempt at some later time,
all dynamic port blocks for the shared outside IP address may be allocated by other subscribers.
In this case, the next allocation attempt for the dynamic port block allocation would fail.
However, Release 11.0.R1 adds the support to prevent such starvation of dynamic port blocks
for the subscribers with static port forwards, a dynamic port block will be optionally reserved
during the lifetime of the static port forward. However, a log will not be generated until the
dynamic port block is actually used or completely released.
At the time of the static port forward creation, the dynamic port block will be reserved in the
following fashion:
If the dynamic port block for the subscriber does not exist, then a dynamic port block for
the subscriber will be reserved. No log for the reserved dynamic port block is generated
until the dynamic port block starts being utilized.
61
ANCP
If the corresponding dynamic port block already exists, then it will be reserved after the last
mapping within has expired. The reserved dynamic port block will continue to be
associated with the same subscriber until the static port forward is deleted and the last
mapping within expires. The log will be generated only when the last mapping in the
dynamic port block expires and the block is completely released (subscriber does not have
any static port forwards left).
ANCP in Release 11.0.R1 supports database persistency, RADIUS ANCP (access-loopinformation) attributes, version 0x31 and 0x32, partitioning, and IDLE filter.
Prior to Release 11.0.R1, communication path interruption between the Access Node ANCP
agents and the BNG ANCP agents could have caused purging of subscribers ANCP attributes
from the BNGs database. To ensure subscriber information persists through different types of
communication interruptions, a new feature called database persistency will cache
subscribers ANCP information in memory. This will allow subscribers ANCP data to be
readily available for RADIUS if GSMP terminates and through CPM failover.
RADIUS authentication and accounting has a selectable "access-loop-options" attribute. This
command, when enabled, will include Broadband Forum (BBF) access loop characteristics,
DSL line state and DSL type. Information obtained via the ANCP protocol will have preference
over information received from PPPoE vendor-specific BBF tags and DHCP vendor-specific
BBF options.
ANCP version 0x31 and 0x32 are both supported and will be auto detected at the start of each
ANCP session. Within version 0x32, partitioning is also supported. Multiple partitions from the
same access node are also supported. If partitions are used, they are automatically detected
during the start of an ANCP session.
A new IDLE filter will detect a subscriber DSL-line-state, and filter them out if they are in state
IDLE.
DHCP relay
enhancements
Uniform RADIUS
server
configuration
62
Release 11.0.R1 introduces the following enhancements to DHCP relay:
GRT-leaking can now be used to relay DHCPv4 and DHCPv6 messages between a VRPN
and the Global Routing Table (GRT). The DHCP relay can be configured on a groupinterface or regular interface in either the VPRN or GRT routing instance.
For deployments where it is not possible to leak the DHCPv4 client subnets into the routing
instance of the DHCPv4 server, it is now possible to configure the gi-address of a DHCPv4
relayed message to any local address that is configured in the same routing instance.
Unicast renewals will in this case also be relayed to the intended DHCPv4 server.
Optionally, the source IP address of all DHCPv4 relayed and release messages can be
updated.
To align RADIUS server configuration and functionality for different applications, with
Release 11.0.R1, it is now possible to configure RADIUS servers to be used for subscriber host
authentication and accounting in a radius-server-policy:
configure subscriber-mgmt authentication-policy name radius-server-policy radius-serverpolicy-name
configure subscriber-mgmt radius-accounting-policy name radius-server-policy radiusserver-policy-name
Prior to Release 11.0.R1, RADIUS servers for Enhanced Subscriber Management were
configured in the authentication and accounting policies. The two RADIUS server
configuration methods co-exist in Release 11.0.R1. It is recommended to migrate existing
configurations to this new method to enable new enhancements. The following enhancements
are only available in the uniform RADIUS server configuration:
Accounting On/Off The accounting on/off behavior is controlled from within the radiusserver-policy. The operational state of the radius-server-policy can be changed based on the
reachability of the RADIUS server (reception of an accounting response for the
Accounting On request).
An Accounting On message is sent at power on, after a node reboot, when the acct-on-off
command is configured in a radius-server-policy, or when it is user-triggered with a CLI
command.
An Accounting Off message is sent before an admin initiated node reboot, when the accton-off command is removed from a radius-server-policy, or when it is user-triggered with a
CLI command.
PPP
enhancements
Buffering of accounting messages When all servers in a radius-server-policy are

unreachable, it is possible to buffer the acct-stop and acct-interim-update messages for up
to 25 hours. When a RADIUS server becomes reachable again, then the messages in the
buffer are retransmitted.
Configurable hold-down time for accounting servers that are marked down and during
which no new communication attempts will be made (hold-down-time).
Configurable maximum number of outstanding RADIUS requests for accounting servers

(pending-requests-limit) Prior to Release 11.0.R1, an internal limit restricted the number
of pending accounting request messages. This internal limit has now been removed for
both RADIUS server configuration methods.
Increased retry and timeout values for unsuccessful RADIUS communication.
Enhanced RADIUS server statistics.
Release 11.0.R1 further enhances PPP as follows:
It is now possible to configure a default session-timeout for PPP sessions: configure

subscriber-mgmt ppp-policy ppp-policy-name session-timeout timeout. A RADIUS
returned [27] Session-Timeout attribute overrides the local configured value.
The maximum length for a PAP password has been increased to 64 chars.
The maximum length for a PPP username has been increased to 253 chars.
PPPoE: RemoteID/Circuit-ID from

local user
database
In PPPoE access scenarios without access nodes or with access nodes that do not insert PPPoE
vendor-specific tags Circuit-ID and/or Remote-ID, Release 11.0.R1 offers the capability to
configure this information in the local user database (LUDB) so that they can be picked up in
the pre-authentication phase and used for RADIUS authentication. Only ASCII string format is
supported.
Subscriber
Services
Starting with Release 11.0.R1, subscriber services enable a new operational model to activate
and deactivate subscriber functions from RADIUS through an access-accept or CoA message.
63
Using the flexible RADIUS Python script interface, the operator defines the subscriber service
functionality by populating a data structure using a parameter list received in a RADIUS
Vendor-Specific Attribute (VSA). The format and content of the parameter list of VSA is
defined by the operator. Each subscriber service instance can have a dedicated RADIUS
accounting session; an accounting start/stop is sent when the subscriber service is
activated/deactivated. Optionally, interim updates are sent with an interim update interval that
can be specified per subscriber-service instance. Accounting interim update and stop messages
contain the subscriber service related statistics (time or volume-and-time).
Subscriber services can be activated on a dual-stack PPPoE session or a single stack IPv4 host.
In Release 11.0.R1, subscriber service functionality is supported for subscriber QoS overrides:
changing queues or policer parameters like rate or burst sizes and adapting root arbiter or
subscriber aggregate rates.
For example, an operator defines a service to boost the downstream rate using the parameters
("rate-limit":downstream-rate-in-mbps). When a subscriber service is activated, and VSA =
rate-limit:20 is received for a PPPoE session, the operator-defined RADIUS Python script
populates the subscriber-service data-structure variable that changes the subscriber aggregate
downstream rate to 20 Mbps. Optionally an accounting start is sent. Later, when a subscriber
service deactivates VSA with the same parameters, and rate-limit:20 is received for the same
PPPoE session, the previous subscriber aggregate downstream rate is restored, and an
accounting stop sent.
RADIUS
enhancements
IPv6 Router
Advertisement
option for DNS
configuration
64
The following RADIUS enhancements are new to Release 11.0.R1:
Attribute value limits have changed for [1] User-Name (253 chars.), [2] UserPassword (64 chars) and [28] Idle-Timeout (180 days).
The information in a [18] Reply-Message attribute is passed on to the PPPoE client in

PAP/CHAP authentication messages.
The interval at which Accounting Interim Updates are sent can now be configured with an
[85] Acct-Interim-Interval attribute in Access-Accept or CoA messages.
Broadband Forum (BBF) access loop characteristics RADIUS attributes (RFC 4679) can
now optionally be included in RADIUS accounting messages via the CLI command
>config>subscr-mgmt>acct-plcy# include-radius-attribute access-loop-options. For
access-loop-options in RADIUS Access-Request and Accounting messages, ANCP
received values have precedence over PPPoE tags or DHCP Option 82.
For RADIUS Accounting session-accounting mode, it is now possible to include all IP

addresses and prefixes obtained at session authentication in the accounting messages,
independent from active/inactive status.
It is now possible to switch off or to limit the random delay introduced on the update
interval between two accounting interim update messages. The maximum jitter value can
be configured between zero and 3600 seconds. The default value is 10% of the configured
update-interval.
It is now possible to include the [5] NAS-Port attribute in RADIUS authentication requests.
With Release 11.0.R1, a Recursive DNS Server Option as defined in RFC 6106 can now be
sent in a Router Advertisement to include DNSv6 configuration information for PPPoE or IPoE
SLAAC hosts. The DNS Search List Option defined in the same RFC is not supported.
Next to RADIUS attributes ([26-6527-105] Alc-Ipv6-Primary-Dns and [26-6527-106] AlcIpv6-Secondary-Dns), the DNSv6 server information can now also be configured in the local
user database (LUDB) or as last resort at the subscriber interface level.
RADIUS-triggered
Dynamic Data
Services
Release 11.0.R1 introduces RADIUS-triggered dynamic data services, which enable a zero
touch, single-ended provisioning model for business services. Triggered by the authentication
of a single or dual stack PPPoE session or single stack IPv4 host as business CPE control
channel, parameters are passed in a RADIUS Access Accept or CoA message to set up a Layer2 or Layer-3 data service. Dynamic data services supported in this release include local Epipe
VLL services, Epipe VLL services with dynamic MS-PWs (FEC129), VPLS services with
BGP-AD PWs, IES, and VPRN services. Dynamic Data Service SAPs have to be located on
dot1q- or qinq-encapsulated Ethernet ports and can be part of a LAG.
A Python script interface adds a flexible abstraction layer reducing the OSS integration cost;
only the business user specific service parameters (service type, IP address, QoS and filter
parameters, etc.) are required from RADIUS and are then used in a CLI template to set up the
target service. Both XML accounting and RADIUS accounting may be enabled on a dynamic
data service SAP. The RADIUS accounting data can be sent to up to two different RADIUS
servers.
A MultiCore-CPU CPM (CPM3 or up) is required to enable dynamic data services. Dynamic
data services are not persistent and are not synchronized in Multi-Chassis Redundancy
scenarios.
RADIUS shared
filter entries
Release 11.0.R1 allows for the locally configured IP or IPv6 filter with dynamic filter entries to
be shared with multiple subscriber hosts. The shared dynamic filter entries are inserted with a
set of RADIUS attributes [242] Ascend-Data-Filter or [26-6527-158] Alc-Nas-Filter-RuleShared received in a RADIUS access-accept or CoA message. A CoA message containing a
set of one of those attributes overrides the previous set of shared filter entries that are active for
that subscriber host.
For each unique set of dynamic filter entries received per type (IPv4/IPv6) and direction
(ingress/egress), a copy is made of the local filter with the dynamic entries included at a preconfigured insert point. If the same set of dynamic filter entries is sent to subscriber hosts that
have the same associated local filter, then they will share the same filter copy.
The target application is operators that have a predefined limited number of different filter lists
that each are shared with multiple subscriber hosts and that are to be managed and activated
from RADIUS at authentication. Refer to the Known Limitations on page 183.
RADIUS
subscriber-host
specific filter
entries
enhancement
Release 11.0.R1 offers a new RADIUS attribute, [26-6527-159] Alc-Ascend-Data-Filter-HostSpec, which enables the insertion of subscriber-host-specific filter entries into the active ipfilter for that host. The functionality is identical to the [92] NAS-Filter-Rule attribute that has
been supported since Release 8.0; only the format is different. The formatting of the new
attribute is identical to the [242] Ascend-Data-Filter attribute.
BNG Debug and

Statistics
Improvements
Release 11.0.R1 introduces the following operational enhancements for ESM deployment:
A new show subscriber-mgmt statistics command now displays host/session statistics

(with current value and peak value) of the system or specified port or line card.
65
The following new show commands display extended statistics (with current value and
peak value) of the specified local DHCPv4 or DHCPv6 server:
-
show router router-id dhcp local-dhcp-server svc-name pool-ext-stats
show router router-id dhcp local-dhcp-server svc-name subnet-ext-stats
show router router-id dhcp6 local-dhcp-server svc-name pool-ext-stats
show router router-id dhcp6 local-dhcp-server svc-name prefix-ext-stats
The output of the show aaa radius-server-policy policy-name statistics command has
been extended to include new statistics (i.e., number of failed authentications, average
response time, transaction success ratio, etc.)
The following new filters have been added to the debug service id svc-id ppp command:
-
username
circuit-id
remote-id
msap
A new RADIUS debug command debug router router-id radius replaces the debug
radius command and supports the following functions:
-
filter packet based on packet-type/RADIUS-attribute/VSA
transaction-based debug
A new attr-from-file parameter has been added to the CLI command tools perform
security authentication-server-check, which allows the system to construct the RADIUS
attributes according to a specified text file.
The following new local DHCP server lease events have been added, which can be
controlled by the configure log event-control command.
-
tmnxDhcpSvrLeaseModify
tmnxDhcpSvrLeaseCreate
tmnxDhcpSvrLeaseDelete
NAT
Enhancements
NAT statistics has been enhanced in Release 11.0.R1 to allow operators to trend port usage in
a pool. Port usage can be tracked per protocol for an aggregated number of subscribers. The
execution of the command that shows the port usage in a pool can be periodically triggered by
CRON. The output of the command can be exported in the form of a file to an external storage
for further analysis of historical data.
Deterministic
Large Scale NAT44
Release 11.0.R1 supports deterministic LSN44, which allows the inside IP addresses to be
mapped into the outside IP addresses and corresponding port-blocks based on deterministic
algorithm. The inverse mapping that reveals the subscriber identity behind the NAT is based on
the reversal of this algorithm. This eliminates the need for logging.
A single port-block can be deterministically allocated to a NAT subscriber (inside IPv4 address
in LSN44). In case that the subscriber exhausts all ports in this deterministic port-block, a
dynamic port-block can be optionally allocated to the subscriber. This will allow for dynamic
expansion of the number of ports that the subscriber can use. This subsequent dynamic portblock allocation is non-deterministic and as such, it will be logged. Similarly, all static port
forwards are logged.
66
The reverse query that reveals the identity of the subscriber can be performed directly via CLI
(or MIB), or it can optionally be performed offline via a Python script that is automatically
generated and then manually exported to external storage.
Local DHCP
Server
Enhancements
In Release 11.0.R1, a new drain CLI command has been added to the local DHCPv4 subnet
and local DHCPv6 prefix configuration context. When this command is configured, the system
will not allocate new addresses or renew existing leases from the corresponding subnet/prefix.
Release 11.0.R1 provides the support for the secondary address pool for local DHCP server as
follows:
RADIUS attribute Framed-Pool can optionally include two pool names (e.g.,
primary|secondary) separated by a configurable delimiter.
A new CLI parameter has been added for command address pool pool-name [secondarypool sec-pool-name] in the local user database (LUDB) configuration to return a
secondary address pool name.
Secondary pool will only be used when there is no address available in the primary pool.
Static host is not supported.

RADIUS based
pre-authentication
for LLID (logical
link-ID)
IPv6 support for

HTTP redirection
Encapsulation Tag
Range Support in
LUDB
Release 11.0.R1 adds the support to pre-authenticate a PPPoE subscriber with a separate
RADIUS server to get LLID (logical representation for subscribers physical access line) before
normal subscriber authentication is performed. The authentication policy for the preauthentication step is configured in LUDB. The authentication policy for pre-authentication can
indicate attributes to be included in the pre-authentication request to RADIUS, including NASPort-Id. The LLID is returned in calling-station-ID (RADIUS attribute 31) from the preauthentication RADIUS server. The returned LLID is stored locally with the PPPoE session and
passed during normal subscriber authentication to the RADIUS server in the calling-station-ID
attribute. Based on local configuration, the LLID can be encoded in Calling-Number AVP and
also passed to the LNS. Calling-number format configured under L2TP has been extended to
indicate the inclusion of LLID.
Release 11.0.R1 introduces IPv6 support for HTTP redirection. An IPv6 HTTP-redirect filter
can also be applied on both ESM and regular interfaces, and SAPs.
Release 11.0.R1 allows a range of encapsulation tags (VLAN or ATM VPI/VCI) to be
configured as the LUDB host identification parameter.
This feature supports the following types of hosts:
PPPoE
L2TP LAC host
DHCP
PPPoA
PPPoEoA
67
BNG Redundancy
with ESM over PW
Release 10.0.R4 and higher provide stateful BNG redundancy when the far-end aggregation PE
(A-PE) is dual-homed to two BNGs. Subscriber state between BNGs is syncd using multichassis sync (MCS). For an Epipe-based aggregation service, the redundancy is based on
active/standby PWs from A-PE to dual BNGs. A-PE signals active/standby PW status to peer
BNGs. An SRRP instance per PW-port (group-interface) is required on the BNG, with a
messaging SAP on each PW-port. BNG terminating the active PW assumes the mastership for
the SRRP instance on the corresponding PW-port. SRRP state is tied to the state of the
messaging SAP. The messaging SAP goes down when the underlying PW-port goes down,
based on PW status bit signaled by the A-PE. In this model, there is no SRRP message exchange
between the two BNGs, as there is no L2 path between the BNGs. The purpose of SRRP is to
provide SRRP-aware routing for subscriber routes and managed routes, and/or to be able to use
the redundant (shunt) interface. Downstream traffic for a subscriber that ingresses the backup
BNG can only be shunted to the active BNG, if the corresponding subscriber-interface on the
backup BNG is operationally up. This can be achieved by creating a second empty groupinterface (without SAPs) on the same subscriber-interface with the parameter 'oper-up-whileempty' configured.
Multiple PWs with endpoint configuration is not supported on the BNG.
In case the aggregation service on the A-PE is VPLS, normal SRRP message exchange would
take place between the two BNGs for determining the mastership, and triggering switchover.
Redundancy based on MC-LAG between A-PE and dual BNGs is not supported.
L2TP Tunnel
RADIUS
Accounting
Release 10.0.R4 and higher allow the collection of usage data based either on an L2TP tunnel
and/or L2TP session and sends the accounting data to the RADIUS server. Different RADIUS
attributes, such as Tunnel-Client-Endpoint/Tunnel-Server-Endpoint/Acct-TunnelConnection/Tunnel-Assignment-ID can be used to identify the tunnel or session.
This feature applies to both LAC and LNS.
The system uses ESM accounting data (queue or policer statistics) to compute L2TP
tunnel/session accounting data and has the following limitations:
RADIUS Route
Download
MLPPPoX in
Subscriber
Management
Context
68
If there are n PPPoE hosts sharing the same sla-profile instance and that belong to the same
L2TP tunnel, then L2TP tunnel-level accounting statistics will be n times the actual
statistics.
If a packet is dropped at a place other than ESM queuing or policing, then the statistics will
still include the dropped packets.
Release 10.0.R4 and higher add the support for RADIUS Route Download. This mechanism
periodically polls a RADIUS server for routes to download. The main objective of this feature
is to inform the router, in advance, customer-assigned subnets so that they can be re-advertised
to the corresponding routing protocols. In this way, subscriber bring-up can potentially be done
faster (as the routes are already in place and advertised) and, most importantly, reduce the
routing protocol churn as subscribers connect and disconnect.
Release 10.0.R4 and higher support MLPPPoX (MLPPPoE, MLPPPoA and MLPPPoEoA)
termination of subscribers on 7750 SR LNS.
Fragmentation and interleaving can be enabled on an MLPPPoX bundle containing a single

session (or a link) in order to ensure timely delivery of delay sensitive traffic ahead of low
priority traffic with long transmission delays.
Fragmentation on an MLPPPoX bundle with multiple sessions improves load balancing and
ensures better utilization of available bandwidth.
Local termination (PTA) of MLPPPoX sessions is supported through a 7750 SR node
simultaneously hosting LAC and LNS connected via a VSM2 module or an external loop.
Unnumbered
PPPoEv6
Starting in Release 10.0.R4, IP addresses assigned to PPPoEv6, PPPoAv6 and PPPoEoAv6

hosts can be allocated outside of the address/prefix range pre-configured under the
service>(ies/vprn)>subscriber-host>ipv6 CLI hierarchy. Such IP addresses (subscriber-hosts)
will be installed in the FIB. This functionality is referred to as unnumbered subscriberinterfaces. Although it would be possible to aggregate advertisement of subscriber hosts under
the unnumbered subscriber-interfaces via routing policy, the aggregation would defeat the very
purpose of unnumbered subscriber interface functionality.
Non-Hitless MultiChassis LAC

Resiliency
Starting with Release 10.0.R4, in a dual-homed PPPoEv4/v6 Wholesale/Retail environment

over L2TP, the subscriber-hosts are synchronized via the Multi-Chassis Synchronization
(MCS) protocol. The failover detection mechanism may be implemented via SRRP, MC-LAG
or a combination of both. When an interface or an entire node fails, the newly selected master
sends PADT to all sessions that were moved over from the failed node. In case of interface-only
failure, Call-Disconnect-Notify (CDN) is sent towards the LNS to terminate sessions on the
LNS.
The PPPoE sessions will be reestablished on the newly selected master, but because PADT was
sent to the clients, the recovery time is faster (no need to wait for PPPoE session timeout).
IGMP
Synchronization in
Routed CO
Environment
Synchronization of subscriber IGMP states between redundant BNG nodes will ensure
continuous delivery of multicast services to the subscribers in case of certain types of network
failures. In Release 10.0.R4 or higher, the IGMP states are synchronized between the redundant
nodes via Multi-Chassis Synchronization (MCS) protocol. They are maintained in the MCS
database and are applied to subscribers based on the state transition of the underlying protection
mechanism SRRP or MC-LAG from standby to active (or master).
In case multicast redirection is configured, the redirected L3 interface and corresponding
subscribers must be protected via the same MC-LAG/SRRP protection mechanism. This will
ensure synchronous IGMP switchover for the subscribers and redirected L3 interfaces.
Multicast synchronization with redirection but without MC-LAG will not yield the desired
results. The reason is that in the absence of MC-LAG, L3 interfaces can only be protected by
VRRP while the group-interfaces under which subscribers reside can only be protected by
SRRP. Although these two protection mechanisms are similar in nature, they are still
independent as applied to these two different entities (L3 interface and group-interfaces). In
addition, IGMP on L3 interfaces is unaware of the VRRP state, unlike subscriber IGMP for
subscriber hosts which is aware of SRRP states. Therefore, not only a switchover on the SRRP
path may not guarantee the same on the VRRP path, but also the IGMP states will be processed
differently even though the underlying protection mechanisms (VRRP and SRRP) for the
respective entities (L3 interfaces and group-interfaces) may have the same state. For this reason,
69
the redirected interface and the group-interface must be protected by the same MC-LAG which
warrants the same IGMP processing on both entities (L3 interface and subscriber-hosts under
the group-interfaces).
DHCPv6 Server
Multi-Chassis
Redundancy
Starting in Release 10.0.R4, multi-chassis redundancy has been extended to DHCPv6 server
functionality. IPv6 leases in DHCPv6 server are synchronized in the same fashion as in
DHCPv4 server. In other words, IPv6 prefixes are designated as local and remote. Under normal
circumstances, new IPv6 leases are delegated only from the v6 prefix designated as local while
existing leases can be renewed from local or remote.
In case that the v6 prefixes cannot be synchronized due to inter-chassis link failure, the failover
state of DHCPv6 will undergo several transitions and the duration of each state will be
determined by preconfigured timers. The prefix designated as remote will be eligible for new
address delegation only after Maximum-Client-Lead-Time (MCLT) once the failover state
enters the partner-down state. The peering session (MCS) between DHCP server nodes can be
configured only over IPv4 transport.
WLAN-GW: Per-UE
Lawful Intercept
Release 10.0.R4 and higher add support for mirroring traffic for WiFi subscribers to a mediation
device when the subscriber is under legal intercept. Only IP-only mirror-dest type is supported.
Existing connectivity options (direct P2P, MPLS and IP/GRE) to the mediation device are
supported. In addition, routable-encapsulation (IP/UDP with optional shim-header for
subscriber correlation on the mediation device) added in Release 10.0.R1 is also supported. LI
can be triggered via CLI/SNMP or RADIUS, as supported with ESM.
WLAN-GW: LargeScale NAT
Release 10.0.R4 and higher add the support for both Large-Scale NAT (LSN) and L2-aware
NAT for WiFi subscribers over soft-GRE. NAT can be performed on the same set of ISAs that
are used for WLAN-GW functions by referring to the WLAN-GW ISA group from NAT
configuration. Alternatively, dedicated set of ISAs can be used for NAT function by creating
and referencing a separate NAT-group.
WLAN-GW: Per-AP
Bandwidth
Shaping
Release 10.0.R4 and higher add support for enforcing aggregate downstream bandwidth per
tunnel access point (AP), or per tunnel (AP) and per-retailer if the AP has multiple SSIDs, one
per retailer. The feature also provides for configuring egress QoS policy for the tunnel or tunnel
and retailer (to map FCs to queues, and define scheduling of queues), aggregate-rate limit, and
schedulers.
WLAN-GW: WiFi to
3G/4G
Interworking
Release 10.0.R4 and higher add the support for WiFi to 3G/4G interworking on WLAN-GW
based on setting up per-UE GTP tunnel from WLAN-GW to the mobile packet core. The feature
involves setting up per-UE GTP tunnel from the WLAN-GW to the GGSN or PGW based on
authenticating the UE. Access to only a single access point network (APN) (default WLAN
APN) is supported. This default WLAN APN for the UE is obtained in authentication response
from the AAA server. DNS resolution of default WLAN APN FQDN to obtain a list of
PGW/GGSN IP addresses is supported. In this release, S-NAPTR DNS procedures (RFC 3958)
and A records from DNS server are supported. The APN-FQDN construction is per 3GPP TS
23.003 Release 10 and service parameter as described in 3GPP TS 29.303 Release 8. A single
primary PDP context per UE is supported on the Gn interface (3GPP TS 29.060 Release 8) from
WLAN-GW to the GGSN. Single default-bearer per UE is supported on S2b interface (3GPP
70
TS 29.274 Release 10), and S2a (work-in-progress for SAMOG Release 11) from WLAN-GW
to the PGW. The GTP tunnel setup is triggered via DHCP from the UE after successful EAP
authentication. The IP address for the UE is obtained via GTP from the GGSN or PGW and
returned to the UE in DHCP. IP address preservation when a UE moves from 4G to WiFi is
supported based on signaling of handover bit in GTPv2 for S2a and S2b interfaces. The
bridged WiFi AP connectivity with the WLAN-GW can be soft-GRE based (L2oGRE or
L2VPNoGRE) or can be a native L2 (VLAN). TCP MSS adjustment is supported. The feature
also adds the support for mapping DSCP bits from the inner and/or outer header in downstream
GTP packet to outer IP header in soft-GRE tunnel towards the AP. The DSCP bits also control
local traffic treatment based on classification into a configured forwarding-class. The DSCP bits
from soft-GRE can be mapped to the outer header in the GTP-encapsulated packet in the
upstream direction as well. GTP-U encapsulation requires FP2- or higher-based line cards.
WLAN-GW: Per-UE
Credit Control (For
UEs Over SoftGRE) with DCCA
Release 10.0.R4 and higher add the support for online charging function in WLAN-GW to
control per-UE access based on pre-paid credit. This is based on the existing time and volume
accounting function in 7750 SR, which uses standard Diameter Credit-Control Application
(DCCA). The functions include reserving time or volume quota for rating-groups from OCS
(online charging server), metering the quota, reporting usage against the quota obtained from
OCS, and executing indicated action on exhaustion of the quota. Credit control is always on a
per rating group basis. A rating-group always maps to a category inside a category-map of 7750
SR time and volume-based accounting function.
WLAN-GW:
Configurable PerTunnel Hold-Time
Release 10.0.R4 and higher allow tunnel resources (e.g., bandwidth shaper per tunnel) to be held
for a configurable amount of time after the last active subscriber on the tunnel has been deleted.
If a new subscriber logs in successfully while the tunnel is in hold-down, the existing resource
will be used. In case the line card where the tunnel exists fails and redundancy is triggered, the
existing tunnel in hold-down is torn down, and associated resources are reclaimed.
WLAN-GW:
Application
Awareness (AA)
for WIFI
Subscribers over
Soft-GRE
Release 10.0.R4 and higher qualify existing AA support with ESM for UEs over soft-GRE. The
AA function is performed on the dedicated MS-ISA. Traffic from UEs with AA enabled (as
indicated via existence of an attached application profile), is diverted to the MS-ISA via ingress
QoS policy filters, which identifies the subset of traffic requiring AA.
ESM Host Lockout
Release 10.0.R4 and higher add the support for protecting the BNG control plane and RADIUS
servers from overload due to misconfigured and malicious hosts, thereby minimizing the impact
on operations for legitimate hosts. Examples of conditions that can trigger overload on the BNG
and potentially RADIUS servers include repeated authentication failures (due to misconfigured
Residential Gateway (RG) or malicious user), misconfigured BNG, invalid RADIUS data,
session negotiation failure, BNG resource exhaustion etc. The protection is provided by putting
a host that fails creation into a lockout state for the duration of lockout time. During this time
authentication and ESM host creation is suppressed. Lockout time is exponentially increased on
each successive failure, starting from a configured minimum to a configured maximum time.
The lockout time is reset to configured minimum value after a configurable lockout reset time
expires relative to when the client entered lockout, and no further failures have occurred. A perSAP lockout policy contains lockout related configuration. Lockout is supported for static SAPs
71
(1:1 or N:1) and MSAPs, and includes PPPoE (including LAC) and IPoE hosts, both IPv4 and
IPv6. Per-host lockout can be manually cleared by the operator. Lockout is not supported for
LNS. Host lockout in a Wholesale/Retail scenario is only supported on the wholesaler SAP. The
lockout contexts for hosts belonging to different retailers are centrally managed and linked to
the wholesaler SAP. If host-lockout contexts for a particular retailer needs to be cleared, the
contexts needs to be cleared individually based on MAC-address, remote-id or circuit-id.
NAT Flow Logging
Starting with Release 10.0.R4, flow logging can be enabled per NAT policy for the following
applications:
Large-Scale NAT44
DS-Lite
NAT64
L2-Aware NAT
The format of flow logging follows IPFIX NetFlow10 format as defined in RFC 5101. The data
structures (templates) are defined in RFC 5102, and they are transmitted in configurable
intervals between four (4) minutes and one (1) day delay with a default of ten (10) minutes. In
addition, several Alcatel-Lucent proprietary fields (inside service ID, outside service ID and
NAT subscriber string) are provided. These are fields that are part of the data send to the
collector. The types are:
Ent Typ = aluInsideServiceId
Ent Typ = aluOutsideServiceId
Ent Typ = aluNatSubString
The flow records are streamed in UDP messages (dest port 4739) to an external flow collector.
Due to stateless nature of UDP, the transport stream contains sequence numbers so that the
packet loss can be identified. Interpretation of the flow records is left to the collector node. This
feature has actually been supported since Release 10.0.R1.
Subscriber-Aware
Large-Scale
NAT44
Release 10.0.R4 introduced subscriber-aware Large-Scale NAT44 (LSN), which brings BNG
subscriber awareness in LSN via local RADIUS Accounting proxy. Local RADIUS Accounting
proxy is caching relevant attributes (such as framed-ip address, user-name, alc-subscriberstring, etc.) from a subscriber instantiated in BNG (BNG subscriber) and using them to correlate
the BNG subscriber with the LSN subscriber. It is not necessary that the LSN node and the BNG
node are collocated.
The purpose of subscriber aware LSN is twofold:
72
To release LSN resources immediately after the BNG subscriber is terminatedBNG

subscriber termination event will be communicated to the LSN via Accounting-Stop
message sent to the RADIUS Accounting proxy, and consequently relevant resources will
be released. It is not necessary that LSN RADIUS logging be enabled for this functionality.
To use information about individual BNG subscribers obtained through BNG accounting in
the management of LSN subscribersWith plain LSN RADIUS logging, port-block
allocation/de-allocation is reported for the LSN subscriber without correlation to the BNG
subscriber. Subscriber awareness in LSN correlates the LSN subscriber with the BNG
subscriber and consequently passes BNG-subscriber-related RADIUS attributes in LSN
RADIUS Accounting messages.
The key to identifying BNG subscribers in LSN is based on framed-ip-address, service-id and
one of the following configurable attributes:
User-name
(standard RADIUS attribute)
Subscriber-id
(Alcatel-Lucent VSA attribute)
Class
Calling-station-id
IMSI
(3GPP AVP)
IMEI
(3GPP AVP)
LSN subscriber instantiation can optionally be denied in case that the BNG subscriber cannot
be identified in LSN via RADIUS Accounting proxy.
Port Control
Protocol (PCP)
Release 10.0.R4 and higher support Port Control Protocol (PCP). PCP is a protocol that operates
between subscribers and the LSN functionality of the 7750 SR, permitting the subscriber direct
but limited control over NAT behavior. PCP is designed to allow a subscriber to configure portforwards, obtain information about existing port-forwards and to obtain the outside IP address
from the LSN. PCP support in SR OS is based on the IETF PCP working group Internet-Draft
draft-ietf-pcp-base.
Quality of Service
The following features are new to Quality of Service features in Release 11.0.R1.
New LAG adaptQoS option for
egress QoS on
access
Starting in Release 11.0.R1, the existing adapt-qos functionality configured under the
config>lag>access>adapt-qos context has been enhanced to support a new mode: distributed
include-egr-hash-cfg. This new mode allows SAPs that have egress hashing configured to hash
to a single lag port to behave as per adapt-qos link mode, while SAPs that have hash configured
for a spray over multiple ports of the same LAG to behave as per adapt-qos distributed mode.
If MSS is configured on the LAG, it will behave as per adapt-qos distributed mode. The new
QoS mode is supported only on a LAG with services that support per-link-hash or LAG linkmap-profile features. The following apply:
The feature requires chassis mode D
LAG mode must be access or hybrid
Cannot change from adapt-qos distribute include-egr-hash-cfg to adapt-qos distribute

when link-map-profiles or per-link-hash is configured
Cannot change from adapt-qos link to adapt-qos distribute include-egr-hash-cfg
This feature is not supported on 7750 SR-1, 7450 ESS-1 and 7710 SR-c4/c12.
Optimized egress
QoS resource
allocation for Link
Aggregation
Groups (LAGs)
Starting with Release 11.0.R1, an operator can optimize egress QoS resources consumed on a
LAG by configuring per-fp-egr-queuing option. When selected, the number of egress QoS
resources (such as queues or schedulers consumed on a given LAG by SAPs and by any encap
groups that exist on those SAPs) can be reduced, as resources are allocated per forwarding
complex LAGs ports reside on instead of per each LAG port.
73
Access-Egress
Queue Group
Instances
Release 10.0 introduced a number of enhancements to queue sharing and redirection on access
ingress and network ingress and egress. In particular, it introduced a queue group provisioning
model that enabled a queue group template to be replicated as multiple queue group instances
on an ingress forwarding plane and on a port on network egress. One or more named queue
group templates could be instantiated one or more times on a given ingress forwarding plane or
egress network port.
Release 11.0.R1 extends the instance based provisioning model to queue groups on access
egress ports. Ethernet egress port queue group instance is now supported for all ethernet based
ports including the HS-MDAv2 hardware. An example application for this feature is as follows:
To enable sets of egress SAPs, which represent a subset of the total number on egress
SAPs, each set representing a bundle of services provided to a given customer, to be shaped
as a bundle using an egress port queue group.
To enable multiple bundles to be shaped according to the same or different queue group
templates, with different queue parameters applicable to each instance of the queue group.
Queue parent parameter overrides are supported to enable different instances of the same queue
group template to have H-QoS queues with different parameters. This is in addition to the
existing queue overrides supported in the existing access egress queue group implementation.
Queue overrides are also supported on HS-MDA queue groups. Note that there is no concept of
a queue parent on the HS-MDAv2.
Access-egress-port queue-group instances can be provisioned using the existing provisioning
model, in which the queue-group instance to redirect SAP-forwarding-class queues to is
specified in the SAP egress QoS policy (policy-based provisioning). Alternatively, a new model
similar to that on access-ingress FP queue groups can be used, where only the forwarding
classes to redirect are specified in the QoS policy, and the actual queue-group instance to use is
named at the time the QoS policy is applied to the SAP (SAP-based redirection). The HS-MDA
queue groups only support SAP-based redirection.
DSCP/IP
Precedence-Based
PW Egress Packet
Re-Classification
This feature, introduced in Release 10.0.R4, allows the user to perform egress re-classification
of IP packets forwarded within a Pseudowire (PW), based on matching a DSCP or an IP
Precedence criterion.
The IP precedence bits used to match against the re-classification rules come from the Type of
Service (ToS) field within the IPv4 header or the Traffic Class field from the IPv6 header. The
IP DSCP bits used to match against the re-classification rules come from the Type of Service
(ToS) field within the IPv4 header or the Traffic Class field from the IPv6 header. If the packet
does not have an IP header, DSCP or IP-precedence based matching is not performed.
Note that the IP-precedence- and DSCP-based re-classification are only supported on a spokeSDP used in an IES or VPRN spoke-interface and when the spoke-SDP is redirected to use an
egress port queue-group. Note that once the spoke-SDP is redirected, re-classification will occur
regardless of whether the queue group instance actually exists or not on a given egress network
port.
Policer Parameter
Override Support
74
Support for overriding the parameters of policers defined in ingress access forwarding plane
queue groups was added in Release 10.0.R4. This feature is supported on all hardware that
supports ingress access forwarding plane queue groups.
Routing
The following sections describe the new routing features in Release 11.0.R1.
6PE Routes
Resolved by Static
Black-Hole Route
In Release 11.0.R1, the support for 6PE routes to be resolved to a black-hole route has been
added. This capability is important for supporting Remote-Triggered Black-Hole (RTBH)
functionality in networks using 6PE for IPv6 transport across an IPv4 MPLS core.
Prior to Release 11.0.R1, 6PE routes had to be resolved to IPv4 next-hops that were present in
the tunnel-table. Starting with Release 11.0.R1, 6PE now supports resolving routes that have a
next-hop of the type black-hole in the RTM.
The black-hole routes may be installed as IPv6 routes or IPv4 routes (e.g., static-route
0100::1/128 black-hole, static-route ::FFFF:192.0.2.1/128 black-hole are both supported for
6PE to resolve the next-hop to the black-hole).
Ethernet
Unnumbered
Interfaces
Starting in Release 10.0.R4, the ability to configure Ethernet unnumbered interfaces has been
added to support some service types for IPv4. The unnumbered interface capability has been
available for other interface types on SR OS. Unnumbered Ethernet allows point-to-point
interfaces to borrow the address from other interfaces such as system or loopback interfaces.
This feature enables unnumbered interfaces for some routing protocols (IS-IS and OSPF) in
Release 10.0.R4 and higher. Support for routing is dependent on the respective routing protocol
and service. This feature also adds support for both dynamic and static ARP for unnumbered
Ethernet interfaces to allow interworking with unnumbered interfaces that may not support
dynamic ARP.
An unnumbered interface is an IPv4 capability only used in cases where IPv4 is active (IPv4only and mixed IPv4/IPv6 environments). When configuring an unnumbered interface, the
interface specified for the unnumbered interface (system or other) must have an IPv4 address.
Also, the interface type for the unnumbered interface will automatically be point-to-point.
Unnumbered Ethernet can be used in IES and VPRN access interfaces, as well as in a network
interface.
Multiple MS-ISAs
in a Tunnel-Group
Routing Policy
Subroutines
Release 10.0.R4 and higher allow up to 16 MS-ISAs to be configured in the same tunnel-group.
A configurable number of all configured MS-ISAs are selected as the active MS-ISAs while the
rest are selected as standby. IPsec/IP tunnels are load-balanced to all active MS-ISAs. This
feature allows operators to expand tunnel-group capacity without changing the tunnel
configuration.
With Release 11.0.R1, it is now possible to reference a routing policy from within another
routing policy to construct powerful subroutine-based policies.
A single level of policy subroutines is supported. Policy subroutines may evaluate true or false
through matching and policy entry actions. A policy entry action of accept will evaluate as
true while a policy entry action of reject will evaluate as false.
To support this functionality, a new policy from match type is introduced that references the
sub-policy.
75
Cflowd
enhancements:
increased cache
scaling on XRS
In Release 11.0.R1, the Cflowd processing engine has been optimized on the 7950 XRS
platform to utilize multiple processor cores on the 7950 XRS CPM card. As a result, sampled
traffic is distributed over up to six (6) different CPU cores to increase the overall flow analysis
rate. With this enhancement, traffic is distributed to different CPU cores based on the flow
characteristic to achieve better utilization of CPU resources.
IPv4 Address
Prefix Lists for
Line Card Filter
Policy Match
Criterion
Release 10.0.R4 and higher introduce a new concept of match lists for line card filter policies
(ACL) and allows the configuration of multiple IPv4 address prefix lists that can be referenced
by CPM and/or line card filter policies in src-ip and dst-ip match criteria. IPv4 filter prefix lists
greatly simplify line card filter policy management. A single configuration entry, instead of
many filter policy entries prior to this feature can be created by grouping address prefixes into
a list. Also, since a list can be shared between many line card filter policies, a single update to
a lists prefixes is automatically propagated to all filter policies using that list.
Since an IPv4 prefix list is likely to contain many prefixes, careful consideration must be given
to resource planning as a single filter policy entry will be expanded to many hardware entries
as required by the entry list configuration and other match criteria in that entry.
IPv6 Address
Prefix Match List
Support for Line
Card Filter Policies
Release 11.0.R1 extends the match list support in line card and CPM filter policies. The operator
can now configure multiple IPv6 address prefix lists that can then be referenced by CPM and/or
line card IPv6 filter policies in src-ip and dst-ip match criteria. IPv6 filter prefix lists greatly
simplify line card and CPM filter policy management by enabling the grouping of prefixes into
a list and then using the list in filter policies. An update to a lists prefixes is automatically
propagated to all filter policies using that list.
Since an IPv6 prefix list is likely to contain many prefixes, careful consideration must be given
to resource planning as a single filter policy entry will be expanded to many hardware entries
as required by the given entry list configuration and other match criteria in that entry.
Enhanced Line
Card Filter (ACL)
policy system
scale
Release 11.0.R1 introduces improved Line-Card-Filter (ACL) policy scale for IPv4, IPv6 and
MAC filter policies. The system scale limit has been increased for each of the above system
filter policies and for respective filter policy entries. The IOM/IMM/XMA hardware limits
remain unchanged. Only the filter policies and entries that are active on a given line card are
downloaded to it. SR OS manages system limits to ensure per-line-card limits are not exceeded.
Route Policies for

BGP Next-Hop
Resolution and
Peer Tracking
Release 11.0.R1 adds the flexibility to attach a route policy to the BGP next-hop resolution
process; it also allows a route policy to be associated with the optional BGP peer-tracking
function. BGP next-hop resolution is a fundamental part of BGP protocol operation; it
determines the best matching route (or tunnel) for the BGP next-hop address and uses
information about this resolving route in the best path selection algorithm and to program the
forwarding table. Attaching a policy to BGP next-hop resolution provides more control over
which IP routes in the routing table can become resolving routes; note however, that the policy
has no effect on the resolution of BGP routes by MPLS tunnels. Similar flexibility is also
available for BGP peer-tracking, which is an optional feature that allows the session with a BGP
neighbor to be taken down if there is no IP route to the neighbor address, or if the best matching
IP route is rejected by the policy.
76
VPRN Support for

BGP
Confederations
BGP FlowSpec
Enhancements
Release 11.0.R1 introduces the ability for VPRNs to participate in BGP confederations;
previously, only the base router BGP instance supported this option. When a VPRN is
configured to belong to a BGP confederation, it can set up confederation-EBGP sessions with
CE router peers that belong to different sub-ASs of the confederation. A VPRN that belongs to
a confederation cannot import or export VPN-IP routes.
Release 11.0.R1 adds the following capabilities to the BGP FlowSpec implementation in
SR OS:
IPv6 support, per draft-ietf-idr-flow-spec-v6-02
VPRN BGP support for the flow-ipv4 and flow-ipv6 address families and the ability to
configure FlowSpec filtering on VPRN IP interfaces. Only AFI=1&2/SAFI=133 is
supported (SAFI=134 is not supported). Because of the introduction of FlowSpec in the
VPRN context, the base FlowSpec filter is renamed from fSpec-1 to fSpec-0.
Aggregate Route
Indirect Next-Hop
Option
Release 11.0.R1 adds the ability to configure an indirect next-hop for aggregate routes. The
indirect next-hop specifies where packets will be forwarded if they match the aggregate route,
but not a more-specific route in the IP forwarding table.
Support for IPv4

address family in
OSPFv3
Release 11.0.R1 introduces support for the IPv4 address family within the OSPFv3 protocol. In
releases prior to Release 11.0.R1, on dual stack interfaces using the OSPF protocol, it was
necessary to run both OSPFv2 and OSPFv3 to dynamically exchange routing information for
IPv4 and IPv6 routes. With this extension, both IPv4 and IPv6 routing information can be
exchanged via the single OSPFv3 protocol, reducing administrative and operational overhead
in configuration.
BGP Fast-Reroute
for Labeled IPv4
Routes
Release 11.0.R1 extends BGP Fast-Reroute (FRR) support to labeled-IPv4 routes. BGP FRR is
a feature that brings together indirection techniques in the forwarding plane and precomputation of BGP backup paths in the control plane to support FRR of BGP traffic around
unreachable/failed next-hops.
MAC Accounting
The MAC accounting feature in Release 11.0.R1 allows statistics to be collected about the
amount of traffic flowing to and from MAC addresses reachable through a specific Layer 3
interface (network interface, IES SAP or VPRN SAP). The MAC accounting feature counts all
non-multicast Ethernet frames carrying an IPv4, IPv6 or MPLS packet. Counting begins for a
MAC address when it is discovered as part of the IPv4 ARP or IPv6 ND process. The latest
counter values are available using CLI show commands and SNMP.
Static Routes for

BGP Route Flap
Suppression
Release 11.0.R1 introduces a new type of static route that dynamically derives its next-hop from
the best BGP route for the exact same IP prefix. One use case of this functionality is the ability
to suppress BGP route flaps for a specific IP prefix.
77
Associate
Communities with
Static and
Aggregate Routes
OSPF LSA
Filtering
BGP AIGP Metric

Attribute
Multicast only
Fast-Reroute
(MoFRR) for native
IP networks
Release 11.0.R1 introduces the ability to associate a BGP standard community with any static
or aggregate route. This provides a convenient way for the route to be matched by a route policy
entry (by specifying a community match) and causes the community to be automatically added
if/when the static or aggregate route is exported into BGP.
Release 11.0.R1 introduces the option to filter outgoing OSPF LSAs on selected OSPFv2 or
OSPFv3 interfaces. This feature should be used with some caution since it goes against the
principle that all OSPF routers in an area should have a synchronized Link State Database
(LSDB), but it can be a useful saving resources in certain hub and spoke topologies where
learning routes through OSPF is only needed in one direction (e.g., from spoke to hub).
The accumulated IGP (AIGP) metric attribute is a new BGP path attribute in Release 11.0.R1,
as described in draft-ietf-idr-aigp-06. Use of the AIGP metric attribute as described in this draft
allows BGP path selection for certain destinations to be based on the end-to-end IGP metrics of
the different BGP paths, even when these BGP paths span more than one AS and IGP instance.
To minimize service interruption to end users and protect the network from sudden surge of
unicast requests, Release 11.0.R1 adds the support for a fast failover scheme for native IP
multicast networks. SR OS MoFRR implementation follows draft-karan-mofrr-02 and relies
on:
Sending a JOIN to a primary and a single standby upstream nodes over disjoined ECMP
paths
Fast failover to a standby stream upon detection of a failure
MoFRR is supported on IPv4 PIM SSM Rosen Multicast networks with MDT SAFI.
Separate IPv4 and
IPv6 statistics on
ingress interfaces
and uRPF
Release 11.0.R1 adds the support for separate ingress IPv4 and IPv6 statistics on IP interfaces.
This includes IES interfaces, VPRN interfaces, subscriber group interfaces on IES and VPRN,
and uRPF. In releases prior to Release 11.0.R1, the ingress statistics for IPv4 and IPv6 traffic
were combined into a single set of packet and bytes counters. The existing counters will now
only count IPv4 traffic, while new separate counters are available for IPv6 traffic. A new CLI
command has been added to explicitly enable ingress statistics of IP interfaces, changing the
default to disabled.
A new CLI command has been added to explicitly enable ingress statistics of IP interfaces,
changing the default to disabled. Enabling the collection can lower forwarding performance for
very small packets.
Note that this feature also introduces a change to the way interface statistics are kept if a packet
is discarded (e.g., due to failing a uRPF check). Prior to Release 11.0.R1, discarded packets
were not counted in ingress service interface statistics. Starting in 11.0.R1, all offered packets
are included in ingress service interface statistics. This feature requires FP2- or higher-based
line cards.
This feature affects the following statistics:
78
IP offered packet counter
IP offered octet counter
IPv6 offered packet counter
IPv6 offered octet counter
IPv4 uRPF failed packet counter
IPv4 uRPF failed byte counter
IPv6 uRPF failed packet counter
IPv6 uRPF failed byte counter
ECMP and BGP

FRR Optimization
and Label-perPrefix Routes
Release 11.0.R1 reduces BGP convergence time when there is a failure of a BGP next-hop, and
IP traffic needs to be redirected to the remaining ECMP paths or to the BGP backup path, and
some of the BGP paths are derived from label-per-prefix routes.
IP-in-IP Tunneling
support
Release 10.0.R8 introduced the capability to terminate IPv4-in-IPv4 tunnels on 7750 SR-7/12
using the MS-ISA to support the encapsulation functions. IP-in-IP tunnels are similar in
function and application to IP/GRE tunnels, which have been supported since Release 8.0.R5.
MBGP for
Incongruent
Topology in mVPN
Release 10.0.R5 and higher provide an option to enable non-congruent unicast and multicast
topologies within mVPN. Operators who prefer to keep unicast and multicast traffic on separate
links in the network now have the option to maintain two separate instances of the route table
(unicast and multicast) per VPRN. Multicast BGP can be used to advertise separate multicast
routes using Multicast NLRI on the PE-CE link within the VPRN instance. Multicast routes
maintained per VPRN instance can be propagated between PE-PE using BGP Multicast-VPN
NLRI (SAFI 129).
GRE tunnel
support on Multiactive Tunnelgroup
Release 10.0.R5 and higher add GRE tunnel support on multi-active tunnel-groups. Multiactive tunnel-group was introduced in Release 10.0.R4 and allowed up to 16 active MS-ISAs in
a single tunnel-group, and prior to Release 10.0.R5, only IPsec tunnels were supported.
Multi-chassis
IPsec redundancy
Starting with Release 10.0.R5, multi-chassis IPsec redundancy (MC-IPsec) provides a 1:1 interchassis stateful failover mechanism for IPsec tunnels. This feature provides protection for
chassis failure and MS-ISA failure. The granularity of failover is per tunnel-group, which means
a specific tunnel-group could failover to standby chassis independent of other tunnel-groups.
An IP-based mastership protocol is used to elect the mastership. IPsec states are synchronized
between chassis by MCS so that there is no need to re-establish existing tunnels upon
switchover. IPsec traffic could be attracted to master chassis by using MC-IPsec-aware route
policies to export IPsec routes to routing protocol and the route metric could then be changed
according to the mastership changes. This feature only supports IKEv2 static LAN-to-LAN
tunnels on a multi-active tunnel-group in Release 10.0.R5 and higher.
The following setup has been qualified for deployment:
- Layer-2 network + VRRP on the public side
- MC-IPsec aware route policy to export static routes to BGP on the private service
- SAP connection for inter-chassis shunting on both public and private sides.
79
IP FRR Using
Loop-Free
Alternate for IPv6
and VPN-IPV6
Prefixes in Both
IS-IS and OSPF
Release 10.0.R4 and higher extend the support of IP Fast-Reroute (FRR) based on Loop-Free
Alternate (LFA) backup for IS-IS and OSPF to IPv6 prefix packets forwarded in the base router
instance over a network IP interface, or over an IES SAP or spoke interface. It also extends the
support to VPRN OSPF VPN-IPv6 prefix packets forwarded to a VPRN SAP or spoke interface.
IP FRR support for

IGP Shortcuts with
IS-IS Prefixes
Release 10.0.R4 and higher provide the use of RSVP LSP based IGP shortcuts as a Loop-Free
Alternate (LFA) backup to expand the coverage of IP Fast-Reroute (FRR) capability. Two LSP
level configuration options are provided.
This feature is supported on 7950 XRS, on 7750 SR-7/12 in chassis mode D, on 7450 ESS6/6v/7/12 in chassis mode D with or without mixed-mode, and on 7750 SR-c4/12.
The lfa-protect option includes the RSVP LSP in both the main SPF and the LFA SPFs. If the
prefix primary Next-Hop (NH) is tunneled, no LFA NH is computed. The protection in this case
is provided by RSVP FRR. If the prefix primary NH is direct, then a LFA NH is computed. A
direct LFA NH is preferred over a tunneled LFA NH. Within each LFA NH type, a node-protect
is preferred over a link-protect.
The lfa-only option includes the LSP in the LFA SPFs only so that the introduction of IGP
shortcuts does not impact the main SPF decision. The prefix primary NH is always direct and
the prefix LFA NH is computed. A direct LFA NH is preferred over a tunneled LFA NH. Within
each LFA NH type, a node-protect is preferred over a link-protect.
This feature is supported on 7750 SR-7/12 in chassis mode D, on the 7450 ESS-6/6v/7/12 in
chassis mode D with or without mixed-mode, on the 7950 XRS, and 7750 SR-c4/12.
IP FRR Support
with BGP NextHop Resolution
Release 10.0.R4 and higher extend IP FRR to protect the path to a BGP neighbor. A BGP prefix
will remain up when the IGP activates the LFA backup next-hop to reach the BGP neighbor
which advertised the prefix.
LDP FRR Support

For IGP Shortcut
With IS-IS FEC
Prefixes
Release 10.0.R4 and higher provide the use of RSVP LSP based IGP shortcuts as a Loop-Free
Alternate (LFA) backup to expand the coverage of LDP Fast-Reroute (FRR) capability. Two
LSP-level configuration options are provided:
BGP Resolving
Next-Hop to BGP
80
The lfa-protect option includes the RSVP LSP in both the main SPF and the LFA SPFs. If
the FEC prefix primary Next-Hop (NH) is tunneled, no LFA NH is computed. The
protection in this case is provided by RSVP FRR. If the FEC prefix primary NH is direct,
then a LFA NH is computed. A direct LFA NH is preferred over a tunneled LFA NH.
Within each LFA NH type, a node-protect is preferred over a link-protect
The lfa-only option includes the LSP in the LFA SPFs only such that the introduction of
IGP shortcuts does not impact the main SPF decision. The FEC prefix primary NH is
always direct and the FEC prefix LFA NH is computed. A direct LFA NH is preferred over
a tunneled LFA NH. Within each LFA NH type, a node-protect is preferred over a linkprotect.
Release 10.0.R4 and higher enhance BGP, allowing BGP routes to resolve the next-hop of other
BGP routes. Only IPv4 and IPv6 unicast routes within the base routing context will support this
function. In addition, only a single level of BGP recursion is supported.
Community
Expressions (AND,
OR and NOT
Operators for
Community Lists)
Release 10.0.R4 and higher extend the capability of the current community list structure to
support AND, OR, and NOT operators via the use of community expressions.
Prior to 10.0.R4, community lists operated with AND support only, where all communities
must match to provide a positive match.
community abc members target:1234:111 target:1234:222 target:1234:333
The above example would only match routes that had all three communities.
Release 10.0.R4 and higher allow an operator to configure a community expression using
additional operators to provide flexible matching of communities.
The AND operator provides functionality equivalent to earlier releases; the OR operator
allows for an OR match of communities; and
the NOT operators allows for inverting matches. Operators may be chained (e.g., AND
NOT) if required.
community abc expression target:1234:111 AND target:1234:222 AND target:1234:333
community def expression target:1234:111 OR target:1234:222
community ghi expression target:1234:1.1 AND NOT target:1234:191
The above examples demonstrate the implementation of AND operators that are equivalent
with the previous syntax of community lists, the OR operator that will match a route that has
target:1234:111 or target:1234:222, and AND NOT that will match a route that matches the
regular expression for target:1234:1.1 (that is, any match of 111, 121, 131, 141, 151, 161, 171,
181, 191) except for 1234.191.
Increase of
Policies Applied to
Import/Export
Statements
Release 10.0.R4 and higher increase the number of policies that may be applied to BGP (group
or neighbor) and VRF import or export statements from five (5) to fifteen (15).
IPv6 Policy-Based
Routing
Policy-Based Routing (PBR) enables an IP router to make routing decisions based on a set of
filter based match criteria. PBR allows an administrator to dictate where traffic can be routed,
through specific paths, or whether to forward or drop the traffic. PBR was supported for IPv4
prior to Release 10.0. Release 10.0.R4 and higher extend this functionality to IPv6. This feature
is only supported on 7950 XRS, FP2- and higher-based line cards on the SR/ESS platforms and
7750 SR-c4/c12, and only supported for IP routing (IES, VPRN, base router) services.
Traffic Leaking
from VPRN to GRT
for IPv6
Release 10.0.R4 and higher support traffic leaking from a VPRN to the Global Routing Table
(GRT) for IPv6. This feature is applicable to service providers who want to provide IPv6 VPRN
and Internet services to their customers over a single VPRN interface. IPv6 packets entering the
VPRN interface with this feature enabled will check to see if packet look-up should be done in
the local VPRN or in the GRT. Service providers can use a couple of different strategies to
deploy this functionality. It is possible to deploy a model where any destination prefix not found
in the local VPRN will be resolved in the GRT. It is also possible to indicate specific routes to
be looked up in the GRT, regardless of their presence in the local VPRN. In order to ensure
packets can return to the VRF, service providers will use a route policy to leak the routes and
the next-hop from the local VPRN to the GRT. GRT-leaking and uRPF are mutually exclusive
and cannot be enabled at the same time in the same VRF.
81
This feature is available on the 7950 XRS, 7750 SR-c4/c12, 7750 SR-7/12 and the 7450 ESS7/12 in mixed-mode, and requires FP2- or higher-based line cards.
MPLS
The following sections describe the new MPLS features in Release 11.0.R1.
Pseudowire
Switching for 7950
XRS
Release 11.0.R1 adds pseudowire switching capabilities to the 7950 XRS platform to allow
manual creation of a VLL service by cross-connecting two spoke-SDPs. It includes the
following combinations:
Signaled PW to signaled PW
Static PW to signaled PW
Static PW to static PW.
All VLL types are supported with this enhancement except for Apipes.
Relative Metric in
IGP Shortcut
Release 11.0.R1 allows the user to specify the use of the relative metric for IGP shortcut as per
RFC 3906 with the config>router>mpls>lsp>igp-shortcut relative-metric [offset] CLI
command.
When this feature is enabled, IGP applies the shortest IGP cost between the endpoints of the
LSP, plus the value of a configured offset when computing the cost of the prefix that is resolved
to the LSP.
The offset value is optional and defaults to zero (0). An offset value of zero (0) is used when the
relative-metric option is enabled without specifying the offset parameter value.
The minimum net cost for the prefix is capped to the value of one (1) after applying the offset
Prefix cost = max (1, IGP Cost + relative metric offset).
The offset can be used to enforce the preference of the shortcut path over the other paths for the
prefix. The default offset value of zero (0) means that the topology is updated with IGP metric
of the shortest path between the endpoints of the LSP.
Expanding the
range of the MPLS
LSP
Administrative
metric
Release 11.0.R1 expands the range of the LSP administrative metric to match the maximum
value allowed for an IS-IS link using the wide-metric. This is a 24-bit value and the new range
is now [0 16777215]. A value of zero disables the administrative metric for this LSP.
The metric option under the LSP configuration in MPLS allows the user to override the LSP
operational metric with a static value that will not change regardless of the actual path the LSP
is using over its lifetime. The LSP operational metric matches the metric the active path of this
LSP is using at any given time. By default, the operational metric of a CSPF LSP represents the
cumulative link metric of all of the links the active path is using. For a non-CSPF LSP, the
operational metric is the shortest IGP cost to the destination of the LSP.
The LSP operational metric is used by some applications to select an LSP among a set of LSPs
that are destined to the same egress router. The LSP with the lowest operational metric will be
selected. If more than one LSP with the same lowest LSP metric exists, the LSP with the lowest
tunnel index will be selected. The configuration of a static LSP metric by the user will make
82
sure the LSP always maintains its preference in this selection regardless of the path it is using
at any given time. Applications that use the LSP operational metric include LDP-over-RSVP,
VPRN auto-bind, and IGP-, BGP- and static-route shortcuts.
Support of
Multicast RPF
Check with IGP
Shortcut
Release 11.0.R1 adds the support of multicast Reverse-Path Check (RPF) in the presence of IGP
shortcuts. When the multicast source for a packet is reachable via an IGP shortcut, the prior
implementation fails the RPF check since PIM requires a bi-directional path to the source, but
IGP shortcuts are uni-directional.
This feature provides IGP with the capability to populate the multicast RTM with the prefix IP
next-hop when both the RSVP-shortcut and the multicast-import options are enabled in IGP.
The unicast RTM can still make use of the tunnel next-hop for the same prefix. This change is
made possible with the enhancement by which SPF keeps track of both the direct first hop and
the tunneled first hop of a node which is added to the Dijkstra tree.
T-LDP hello
reduction
Release 11.0.R1 implements a new mechanism to suppress the transmission of the Hello
messages following the establishment of a targeted-LDP session between two LDP peers. The
Hello adjacency of the targeted session does not require periodic transmission of Hello
messages as in the case of a link-LDP session. In link LDP, one or more peers can be discovered
over a given network IP interface and as such, the periodic transmission of Hello messages is
required to discover new peers in addition to the periodic keepalive message transmission to
maintain the existing LDP sessions. A targeted-LDP session is established to a single peer.
Thus, once the Hello Adjacency is established and the LDP session is brought up over a TCP
connection, keepalive messages are sufficient to maintain the LDP session.
When this feature is enabled, the targeted Hello adjacency is brought up by advertising the
Hold-Time value the user configured in the Hello timeout parameter for the targeted session.
The LSR node will then start advertising an exponentially increasing Hold-Time value in the
Hello message as soon as the targeted-LDP session to the peer is up. Each new incremented
Hold-Time value is sent in a number of Hello messages equal to the value of the Hello reduction
factor before the next exponential value is advertised. This provides time for the two peers to
settle on the new value. When the Hold-Time reaches the maximum value of 0xffff (binary
65535), the two peers will send Hello messages at a frequency of every [(65535-1)/local
helloFactor] seconds for the lifetime of the targeted-LDP session (e.g., if the local Hello Factor
is three (3), then Hello messages will be sent every 21844 seconds).
Both LDP peers must be configured with this feature to gradually bring their advertised HoldTime up to the maximum value. If one of the LDP peers does not, the frequency of the Hello
messages of the targeted Hello adjacency will continue to be governed by the smaller of the two
Hold-Time values. This feature complies with draft-pdutta-mpls-tldp-hello-reduce.
Unnumbered
Interface Support
in RSVP
Release 11.0.R1 introduces the use of unnumbered IP interface as a Traffic Engineering (TE)
link for the signaling of RSVP P2P LSP and P2MP LSP.
The support of unnumbered TE link in IS-IS consists of adding a new sub-TLV of the extended
IS reachability TLV, which encodes the Link Local and Link Remote Identifiers as defined in
RFC 5307.
83
The support of unnumbered TE link in OSPF consists of adding a new sub-TLV, which encodes
the same Link Local and Link Remote Identifiers in the Link TLV of the TE area opaque LSA
and sends the local Identifier in the Link Local Identifier TLV in the TE link local opaque LSA
as per RFC 4203.
The support of unnumbered TE link in RSVP implements the signaling of unnumbered
interfaces in ERO/RRO as per RFC 3477 and the support of IF_ID RSVP_HOP object with a
new Ctype as per Section 8.1.1 of RFC 3473. The IPv4 Next/Previous Hop Address field is set
to the borrowed IP interface address.
The unnumbered IP is advertised by IS-IS TE and OSPF TE, and CSPF can include them in the
computation of a path for a P2P LSP or for the S2L of a P2MP LSP. This feature does not,
however, support defining an unnumbered interface for a hop in the path definition of an LSP.
All MPLS features available for numbered IP interfaces are supported, with the following
exceptions:
Configuring a router-id with a value other than system
Signaling of an LSP path with an ERO-based loose/strict hop using an unnumbered TE link
in the path hop definition
Signaling of one-to-one detour LSP over unnumbered interface
Soft pre-emption of LSP path using unnumbered interface
Inter-area LSP
Unnumbered RSVP interface registration with BFD
RSVP Hello and all Hello related capabilities such as Graceful-restart helper
RSVP refresh reduction on an unnumbered interface
The user SRLG database feature The user-srlg-db option under MPLS allows the user to
manually enter the SRLG membership of any link in the network in a local database at the
ingress LER. The user cannot enter an unnumbered interface into this database and as such
all unnumbered interfaces will be considered as having no SRLG membership if the user
enabled the user-srlg-db option.
This feature also extends the support of lsp-ping, p2mp-lsp-ping, lsp-trace, and p2mp-lsp-trace
to P2P and P2MP LSPs that have unnumbered TE links in their path.
IP and LDP FRR
Support for IGP
Shortcuts with
OSPF Prefixes
84
Release 11.0.R1 provides the use of RSVP-LSP-based IGP shortcuts as a Loop-Free Alternate
(LFA) backup to expand the coverage of IP Fast-Reroute (FRR) capability and LDP FRR
capability for OSPF prefixes.
Two LSP-level configuration options are provided:
The lfa-protect option includes the RSVP LSP in both the main SPF and the LFA SPFs. If
the prefix primary Next-Hop (NH) is tunneled, no LFA NH is computed. The protection in
this case is provided by RSVP FRR. If the prefix primary NH is direct, then an LFA NH is
computed. A direct LFA NH is preferred over a tunneled LFA NH. Within each LFA NH
type, a node-protect is preferred over a link-protect.
The lfa-only option includes the LSP in the LFA SPFs only so that the introduction of IGP
shortcuts does not impact the main SPF decision. The prefix primary NH is always direct
and the prefix LFA NH is computed. A direct LFA NH is preferred over a tunneled LFA
NH. Within each LFA NH type, a node-protect is preferred over a link-protect.
The IP FRR feature for OSPF prefixes is supported on 7950 XRS, on 7750 SR-7/12/12e in
chassis mode D, on the 7450 ESS-6/6v/7/12 in chassis mode D with or without mixed-mode,
and 7750 SR-c4/c12.
The LDP FRR feature for OSPF prefixes is supported on 7950 XRS, on 7750 SR-1 and SR7/12/12e in all chassis modes, on the 7450 ESS-1 and ESS-6/6v/7/12 in all chassis modes, and
on 7450 ESS-6/6v/7/12 in mixed-mode. It is also supported on the 7750 SR-c4/c12 and 7710
SR-c4/c12 platforms.
Network IP
Interface Address
as Local LSR-ID in
Link LDP
Release 11.0.R1 allows the user to configure the address of any network IP interface configured
on the system as the LSR-ID to establish link-LDP Hello adjacencies and sessions with directly
connected LDP peers. The network IP interface can be either a loopback or non-loopback.
LSR-ID is the LDP equivalent of router-id in a routing protocol. Link-LDP sessions to all peers
discovered over a given LDP interface share the same local LSR-ID. However, LDP sessions
on different LDP interfaces can use different network interface addresses as their local LSR-ID.
By default, the LDP session to a peer uses the system interface address as the LSR-ID unless
explicitly configured using the config>router>ldp>interface-parameters>interface>local-lsr-id
{system | interface | interface-name} command. Note, however, that the system interface must
always be configured on the router or the LDP protocol will not come up on the node. There is
no requirement to include it in any routing protocol.
Prior to Release 11.0.R1, addresses of network IP interfaces other than system were allowed to
be configured as the LDP LSR-ID in T-LDP sessions. In link-LDP sessions, only the system
interface or the local interface over which the LDP Hello adjacency is established could be
selected as the local LSR-ID.
Automatic ABR
Selection for InterArea LSP
Release 11.0.R1 enhances the implementation of an inter-area RSVP P2P LSP by making the
ABR selection automatic at the ingress LER. The user will not need to include the ABR as a
loose-hop in the LSP path definition.
Prior to Release 11.0.R1, the user was required to indicate that the LSP path was a multi-area
using the cspf-to-first-loose option in CLI and to include the ABR nodes, where the ERO in
the path message was expanded, as loose hops in the LSP path definition. Without these, CSPF
for the LSP path would fail at the head-end node since the TE information for links in another
area was not available.
The cspf-to-first-loose P2P LSP level command has been deprecated in Release 11.0.R1.
Inter-Area LSP
support of OSPF
Virtual Links
The OSPF virtual link extends Area 0 for a router that is not connected to Area 0. As a result, it
makes all prefixes in Area 0 reachable via an intra-area path but in reality, they are not since the
path crosses the transit area through which the virtual link is set up to reach the Area 0 remote
nodes.
The TE database in a router learns all of the remote TE links in Area 0 from the ABR connected
to the transit area but an intra-area LSP path using these TE links cannot be signaled within Area
0 since none of these links is directly connected to this node.
This inter-area LSP feature can identify when the destination of an LSP is reachable via a virtual
link. In that case, CSPF will automatically compute and signal an inter-area LSP via the ABR
nodes that are connected to the transit area.
85
However, when the ingress LER for the LSP is the ABR connected to the transit area and the
destination of the LSP is the address corresponding to another ABR's router-id in that same
transit area, CSPF will compute and signal an intra-area LSP using the transit area TE links,
even when the destination router-id is only part of Area 0.
Inter-Area LSP
Dynamic FRR
Bypass for ABR
Node Protection
Admin Group
Support on Facility
Bypass Backup
LSP
Release 11.0.R1 allows dynamic bypass computation, signaling, and association with the
primary path of an inter-area P2P LSP to provide ABR node protection. Prior to Release
11.0.R1, only manual bypass LSP was supported.
Release 11.0.R1 includes LSP primary path admin-group constraints in the computation of a
Fast-Reroute (FRR) facility bypass backup LSP to protect the primary LSP path by all nodes in
the LSP path.
This feature is supported with the following LSP types and in both intra-area and inter-area TE
where applicable:
Primary path of a RSVP P2P LSP
S2L path of an RSVP P2MP LSP instance
LSP template for an S2L path of an RSVP P2MP LSP instance
This feature is not supported on One-to-One Detour Backup LSP.

LDP P2MP LSP for
Forwarding
VPLS/B-VPLS
BUM and IP
Multicast Packets
Release 11.0.R1 enables the use of an LDP P2MP LSP for forwarding Broadcast, Unicast
unknown and Multicast (BUM) packets of a VPLS or B-VPLS instance. The P2MP LSP is
referred to as the Inclusive Provider Multicast Service Interface (I-PMSI). A node behaves as a
leaf only of the I-PMSI by default. The root-and-leaf CLI command must be enabled for the
node to be both root and leaf of the I-PMSI.
When enabled, this feature relies on BGP Auto-Discovery (BGP-AD) to discover the PE nodes
participating in a given VPLS/B-VPLS instance. The BGP-AD route contains the information
required to signal both the point-to-point (P2P) pseudowires used for forwarding unicast known
Ethernet frames and the LDP P2MP LSP used to forward the BUM frames. Each leaf node will
initiate the signaling of the mLDP P2MP LSP upstream using the P2MP FEC information in the
I-PMSI tunnel information discovered via BGP-AD.
If IGMP or PIM snooping are configured on the VPLS/B-VPLS instance, multicast packets
matching a L2 multicast Forwarding Information Base (FIB) record will also be forwarded over
the P2MP LSP. If the P2MP LSP instance goes down, VPLS/B-VPLS immediately reverts the
forwarding of BUM frames to the P2P pseudowires.
This feature is supported with VPLS, H-VPLS, and B-VPLS. It is not supported with I-VPLS
and Routed VPLS. It is also not supported with BGP-VPLS.
This feature is supported in chassis mode C or higher on 7750 SR-7/12, 7450 ESS-6/7/12, and
mixed-mode on 7450 ESS. It is also supported on the 7950 XRS, 7750 SR-12e, and 7750 SRc4/c12 platforms.
86
Reduction in
MPLS RSVP Trap
Generation
Release 10.0.R4 and higher merge two traps, vRtrMplsXCCreate and vRtrMplsXCDelete, that
can be generated at both LER and LSR into a new specific trap vRtrMplsSessionsModified. In
addition, this feature will perform bundling of traps of multiple RSVP sessions (i.e., LSPs) into
this new specific trap. Note that the MPLS trap throttling will not be applied to this new trap.
Application Assurance Services

The following sections describe the new Application Assurance features in Release 11.0.R1.
AA RADIUS
Accounting and
Charging Group
enhancements
In Release 11.0.R1, AA RADIUS Accounting has been enhanced to provide the support for
App-Group and Application level per subscriber statistics. The primary use of this feature is to
allow RADIUS Accounting to be enhanced with additional AA information in addition to
Charging Group statistics. Similarly, AA Charging Group statistics can now be exported into
XML accounting files.
AA IPv6-IPv4
tunneling Support
In Release 11.0.R1, the MS-ISA supports AA services (application detection, reporting and
control) on traffic encapsulated within DS-Lite tunnels. Fragmented IPv6 DS-Lite packets are
cut-through within the MS-ISA (i.e., not analyzed).
Asymmetry
removal
enhancements
Asymmetry removal has been enhanced in Release 11.0.R1 to support:
Asymmetry between multiple endpoints of an AARP index within a given node
Singlenode operation
Dual-node multi-endpoint AARP indexes
Configurable AARP master selection modes to allow minimize-switchovers mode, reduce

ICL cost with inter-chassis-efficiency mode, or priority-based-balance mode.
Cflowd
Performance
Planning Statistics
In Release 11.0.R1, the MS-ISA collects statistics of different aspects relating to AA Cflowd
operations and exports them as per the configured statistics accounting policy in the system.
This extends the previous MS-ISA CLI show commands relating to Cflowd operations to
provide time-line based information to enable operators to carry different functions of
operational planning and network/system sizing.
Comprehensive
cflowd statistics
record and cflowd
performance
planning statistics
In Release 11.0.R1, the MS-ISA provides another type of IPFIX-10 Cflowd record. This new
comprehensive record type helps operators in two deployments scenarios:
1.
HTTP host and device types Using the new performance Cflowd, operators can collect
statistics regarding the host names and device types being used in different flows within the
network. These per-flow statistics are exported via IPFIX v10 Cflowd formatted records to
a Cflowd collector (such as RAM DCP) to enable intelligent reporting on devices and host
fields.
2.
Scaling of Cflowd In some situations, operators are mainly interested in augmenting the
5-Tuple IP flow information with AA classification of the flow in terms of application/application group. While AA volume Cflowd provides this function, it is enabled at the
AA-partition level, covering all traffic within a partition, which then prohibits the use of
87
high sampling rates. Using the AA comprehensive flow sampled Cflowd mechanism, operators can target (or exclude) certain applications (or application groups) for sampling, providing better control at the application/application group level, rather than at the partition
level (case of volume Cflowd).
Similar to TCP and Audio/Video Cflowd records, AA comprehensive Cflowd is flow-based
sampling per application (or application group), supporting two different configurable sampling
rates.
Time of Day
override policers
In Release 11.0.R1, Time of Day override for policers enables the operator to adjust AA policer
values automatically in the network. Up to eight (8) overrides can be configured per policer,
each using either a daily or weekly time range.
This feature is especially useful in residential and business-VPN where different policy actions
may need to be taken depending on the days of the week and the time in the day.
Session Filter
In Release 11.0.R1, MS-ISA supports a new AA AQP action, called session filter, that allows
MS-ISA to act as a stateful firewall. AA-FW provides stateful UDP/TCP/SCTP and ICMP
inspection and protection, DoS attack protection and application-layer gateway support (ALG).
For example, AA-FW can be configured to block unsolicited traffic, allowing traffic to/from the
subscriber only if it is initiated by the subscriber.
AA RADIUS
Accounting
In Releases 10.0.R4 and higher, AA RADIUS Accounting provides per-aa-subscriber-level

charging group statistics into the RADIUS Accounting infrastructure. The primary use of this
feature is to allow RADIUS Accounting to be enhanced with AA information useful for usagebased billing plans, providing flexibility to charge and rate application content using IP subnets,
HTTP URLs, SIP URIs and other AA-identified applications.
AA Seen-IP transit
Subscribers
Starting with Release 10.0.R4, Seen-IP transit subscriber notification provides RADIUS
Accounting-Start notification of the IP addresses and location of active subscribers within a
parent AA service. This allows a Policy and Charging Rule Function (PCRF) to dynamically
manage RADIUS AA subscriber policy (create, modify, delete) without requiring static
network topology mapping of a subscriber edge gateway to the BRAS parent transit service.
OAM
The following sections describe the new OAM features in Release 11.0.R1.
TWAMP IPv6
ETH-CFM Primary
VLAN
88
Release 11.0.R1 adds the support for IPv6 to the existing TWAMP server functionality.
In Release 11.0.R1, Primary VLAN is supported for Up and Down MEPs, and ingress and
egress MIPs on an Ethernet SAP for Epipe and VPLS service MEPs.
Unsupported Features in 7950 XRS
ETHERNET-CFM
QoS/CoS
Enhancements
Service OAM (SOAM) and the associate tools that fall under the umbrella have aligned
behaviors in Release 11.0.R1. Up and Down MEPs will process the egress QoS policy for
packets that are generated from the node. MPLS EXP bits are properly parsed and sent to the
ETH-CFM application; these are new default behaviors. Since ETH-LTR does not use a
response in kind model, a new optional CLI is available to configure the LTR response priority.
ETH-CFM Support
of Local Switch
ePipe
Prior to Release 11.0.R1, ETH-CFM was introduced with limited supported (ETH-LBM and
ETH-LTM, UP MEPs and MIPs) when deployed with Epipe constructs that took advantage of
SAP to SAP connections with a PBB Tunnel backup. Starting in Release 11.0.R1, support has
been added for all ETH-CFM tools and Management Points (MEP/MIP) within this construct.
802.3ah
Enhancement EFM Passive
Status
With Release 11.0.R1, a new reason code will now be presented when EFM-OAM is
responsible for bringing the port state to Link Up and Operationally Down, "Reason Code:
efmOamDown". Furthermore, operators are allowed to decouple the EFM-OAM protocol from
interacting with the port. This decoupled state means none of the protocol errors encountered
by EFM-OAM will affect the port.
G.8032 for 7750

c4/c12 and ESS6
Starting in Release 11.0.R1, slow timers OAM handling of G.8032 has been extended to support
the full G.8032 Ring on 7750 SR-c4/c12 and 7450 ESS-6/6v. This feature was not available on
these platforms prior to Release 11.0.R1.
This feature also enables Continuity Check messages (CCM) on Ring ports at one (1) second
intervals for all platforms where G.8032 is supported. G.8032 can be configured on additional
SR OS platforms. CCMs are optional with G.8032, but are normally deployed for higher
assurance of protection. The 7950 XRS, 7750 SR and 7450 ESS additionally support CCM of
10ms and 100ms. Since CCM is configured on a neighbor node basis, the only requirement is
that neighbor switches be configured with the same interval or have CCM disabled.
ETH-CFM ETH-CC
Grace Period
Starting in Release 10.0.R4, the ETH-Vendor-Specific Message (ETH-VSM) described in ITUT Y.1731 is used to announce the start of an ETH-CFM grace period. This grace period is
applicable to CCM-Enabled MEPs that are administratively enabled. The grace function will be
announced when the local node enters Soft Reset, and will exit once the function has been
completed. This grace announcement is used to help prevent CCM and active AIS timeouts
during line card Soft Resets. This function is on by default but can be disabled via CLI. This
feature is supported on 7950 XRS, on 7750 SR-7/12/12e, and 7450 ESS-6/6v/7/12 with or
without mixed-mode.
Unsupported Features in 7950 XRS

Although the 7950 XRS shares the same SR OS as the 7750 SR product family, the following
7750 SR features are not supported on the 7950 XRS platforms:
Channelized and TDM interfaces
ATM interfaces
Frame Relay interfaces and services (e.g., Fpipe SAPs)
89
Unsupported Features in 7750 SR-12e
SONET/SDH interfaces
Circuit Emulation services (e.g., Cpipe SAPs)
VSM/CCAG functionality
Functions that require an MS-ISA card on the 7750 SR such as:
Application Assurance
NAT
L2TP LNS
The port-policy command
Tunnel services (IPsec, GRE tunnel termination)
Video services (Retransmission and Fast Channel Change, Video Quality Monitoring,
Local/Zoned Ad Insertion)
Arbor TMS: Threat Mitigation Services
Enhanced Subscriber Management (ESM / TPSDA) and related features

-
DHCP server and proxy (on subscriber interfaces)
DHCP snooping
IGMP reporter
Anti-spoofing filters
PPPoE, PPPoA
L2TP
MC-sync for subscriber management, Local DHCP server, Subscriber host tracking
and SRRP
Capture SAPs and MSAPs
Redundant Interfaces (IES and VPRN)
Named Pools and Named-Pool mode (QoS)
Ingress shared queueing (Dual-Pass)
RADIUS-based VPLS
New-qinq-untagged-sap configurability for :*.0 and :0.0 SAPs (always "on" for the 7950
XRS)
IEEE 1588 (PTP)
Redundant BITS input port operation
Chassis modes
IPv4/IPv6 DHCP Server (IES and VPRN Interfaces)
MPLS-TP
Unsupported Features in 7750 SR-12e

Although 7750 SR-12e belongs to the 7750 SR product family, the following 7750 SR feature
is not supported:
90
Chassis mode
Unsupported Features in 7750 SR-c4 and SR-c12
Unsupported Features in 7750 SR-c4 and SR-c12

Although 7750 SR-c12 and SR-c4 belong to the 7750 SR product family, the following 7750
SR features are not supported on these platforms:
Ingress Multicast Path Management, except bandwidth policies (which are supported)
CPU Protection (CPM DoS Protection)
G.8031 (Ethernet tunnel support)
Sub-second CCM-enabled MEPs
Dynamic Port Buffer Allocation (Named Pools)
Network Address Translation (NAT) - requires BB ISA support with MS-ISA
L2TP LNS - requires BB ISA support with MS-ISA
Video services - requires Video ISA support with MS-ISA
IPsec GRE tunnel termination - requires Tunnel ISA support with MS-ISA (not supported
on 7750 SR-c4 only, and not all IPsec features are available on 7750 SR-c12)
BITS input port redundancy (not supported on 7750 SR-c12 only)
BITS out support (not supported on 7750 SR-c12 only)
VSM Cross-Connect Aggregation (CCA)
Fast MEPs
AARP (not supported on 7750 SR-c4 only)
IEEE 1588 (not supported on 7750 SR-c12 with CFM-XP)
IEEE 1588 port-based timestamping
Major ISSU
Unsupported Features in 7450 ESS

The following features are not supported on the 7450 ESS platform with or without mixedmode1:
Channelized MDAs
MS-ISA support for L2TP LNS, GRE tunnel termination, local/zoned ad insertion Video
service
The following features are not supported on the 7450 ESS platform without mixed-mode:
ATM MDA and services
ASAP MDAs and associated interface types
CES MDAs and associated interface types
Cflowd
1. Refer to Mixed-Mode on page 143.
91
Unsupported Features in 7710 SR
Full VPRN support
BGP for routing (RFC-3107-labeled routes are supported)
IPv6 routing
-
IPv6 routing (Unicast and Multicast)
6PE
6VPE (IPv6 VPRN)
IP Multicast routing and forwarding

-
Protocols: PIM, MSDP and IGMP
mVPN
P2MP LSP support
Spoke termination on L3 (IES/VPRN) interfaces
TPSDA
-
IPv4 and IPv6 routed subscriber management support
PPPoE support
L2TP
SRRP
Routed subscriber management for Wholesale
IP Mirroring
MS-ISA Applications:
-
IPsec
NAT
FCC/RET
When mixed-mode is enabled, the following feature is not supported:
7450 ESS VSM/CCAG (VSM/CCA is only supported on 7750 SR VSM MDAs in IOM3XP when mixed-mode is enabled.)
Unsupported Features in 7710 SR

The following features are not supported on the 7710 SR platform:
92
Ingress Multicast Path Management, except bandwidth policies (which are supported)
CPU Protection (CPM DoS Protection)
G.8031 (Ethernet tunnel support)
Sub-second CCM-enabled MEPs
Dynamic Port Buffer Allocation (Named Pools)
Network Address Translation (NAT) - requires BB ISA support with MS-ISA
L2TP LNS - requires BB ISA support with MS-ISA
Application Assurance - requires AA ISA support with MS-ISA
Video services - requires Video ISA support with MS-ISA
Enhancements
IPsec/GRE tunnel termination - requires Tunnel ISA support with MS-ISA
VSM Cross-Connect Aggregation (CCA)
MDAs and CMAs not listed in Table 5
Routed CO
Class-Fair Hierarchical Policing (H-Pol)
CPM filter MAC criteria (MAF MAC filters)
CPM filter queues
WRED per queue/forwarding class
BITS input port redundancy
BITS out support
Enhanced Subscriber Management (PPPoE)
G.8032 (Ethernet ring protection)
Fast MEPs
Routed VPLS (R-VPLS)
IEEE 1588
Major ISSU
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 11.0.R20 and previous 11.0 releases, see the following spreadsheet
at the Alcatel-Lucent online customer support site:
11.0 AA Protocols and Applications for the 7450 ESS and 7750 SR
For a complete list of all AA protocols and applications, contact your regional support
organization.
Release 11.0.R20
System
IS-IS
Additional checks have been added on Inter-Card Communication (ICC) messages to

prevent card resets in case of bit corruptions in these messages. This enhancement was
actually added in Release 11.0.R17. [183193]
In Release 11.0.R20, both ingress and egress XPL error trap counts will be displayed under
show mda detail. [210513]
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
93
Enhancements
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 11.0.R20, 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 config router ecmp value. [211050]
Services General
In case of a MAC-move rate-exceeded event in an I-VPLS service, the alarm message

previously displayed only the B-VPLS service-ID. With this enhancement, the I-VPLS
service-ID will also be displayed. [210519]
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 reestablished while the MS-ISAs are rebooting on the standby chassis. [208268]
Application
Assurance
The 11.0 AA Protocols and Applications for the 7450 ESS and 7750 SR spreadsheet has
been added to the SR documentation suite. While this is the last planned SR OS 11.0
maintenance release, this spreadsheet may continue to be updated to reflect recent AA
protocol and application updates. A link to the document is also provided at the beginning
of the Enhancements section.
Release 11.0.R19
94
Hardware
10 GBase tunable DWDM SFP+ (low-power 1.5 watts MSA-compliant) is now supported
on the SFP+ based cards. [200880]
ICMP
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
SF/CPM3/4/5 and FP3-based line cards, and on 7950 XRS platforms. [207965]
VRRP/SRRP
Release 11.0.R19 adds SRRP/VRRP to the list of protocols that generate a

tmnxEqDataPathFailureProtImpact event when they are impacted by a data-path recovery
action. [208825]
Application
Assurance
Release 11.0 R19 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
Enhancements
are shown in the table below. For a complete list of the Release 11.0 AA identification
capabilities (protocols and applications), contact your regional support organization.
TABLE 14. New and updated protocols in Release 11.0.R19
Protocol
Status
Comments
Facebook_RTP
new
Provides detection of Facebook voice traffic over

RTP.
League of Legends
new
Provides detection of League of Legends over

HTTP and TLS, and gaming over UDP.
NDMP
new
Provides detection of Network Data Management

Protocol over TCP.
QUIC
new
Provides detection of QUIC (QUIC UDP Internet

Connections) over UDP. QUIC is a new communication 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.
Gnutella
updated
Provides improved detection of Gnutella over UDP

and TCP.
LINE
updated
Provides improved detection of LINE over SPDY.
Microsoft Lync
updated
Provides improved detection of Microsoft Lync

over TCP.
Tango
updated
Provides improved detection of Tango over UDP.
TLS_HTTP2
updated
Provides improved detection of TLS_HTTP2 when

initiated with TCP Fast Open. These flows were
previouly detected at TLS.
Viber
updated
Provides improved detection of Viber audio and

video traffic over UDP.
YouTube
updated
Provides improved detection of YouTube live event

streaming over RTMP.
Release 11.0.R19 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
95
Enhancements
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 11.0.R19 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.
Release 11.0.R18
There are no new enhancements added since 11.0.R17 to 11.0.R18 of SR OS.
Release 11.0.R17
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
three (3) minutes if the fans have failed or their presence cannot be detected. User
intervention is required to recover the system. [162664]
Release 11.0.R17 adds the support for the 2200/2800W APEQs but only in the 2200W
mode. [192315]
Release 11.0.R17 adds the CLI command admin reboot standby hold as a graceful
shutdown mechanism for standby SF/CPM3 and SF/CPM4 on the 7750 SR-7/12 and
7450 ESS-7/12 integrated SFMs. Executing admin reboot standby removes the standby
CPM from being in hold. This enhancement allows for physical removal of the switch
fabric card with minimized traffic interruption. [164292]
In Release 11.0.R17, new log events have been added that are generated when the switch
fabric capacity falls below the line card capacity and when this condition is cleared.
[164487]
Services General
Release 11.0.R17 adds the support for using an SDP with bgp-tunnel enabled for Epipe
spoke SDP termination on IES and VPRN interfaces. [194468]
Subscriber
Management
A new CLI flag ignore-df-bit in the PPP local user database ignores the do-not-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]
Application
Assurance
Release 11.0.R17 supports a new version of the isa-aa.tim file that enables new and
HW/Platform
System
96
Enhancements
Protocol
Status
Comments
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 resumption 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.
QQ
updated
Provides improved detection of QQ traffic over

HTTP and TCP.
Weixin
updated
Provides improved detection of WeChat traffic over

HTTP and TCP.
Release 11.0.R16
Release 11.0.R15
System
Release 11.0.R15 reintroduces statistics collection for IES and VPRN interfaces on iom20g-b and iom2-20g as available prior to Release 11.0, when enable-ingress-stats is
disabled. When enable-ingress-stats is disabled, the statistics collected for such interfaces
on iom-20g-b and ion2-20g is the sum of the SAP packets and the packets directed to the
CPM. When enable-ingress-stats is enabled, only the SAP statistics are reported for these
IOM cards. See Known Limitations on page 183 for restrictions that apply. [186298]
Application
Assurance
Protocol
Status
Comments
OpenVPN
updated
Provides detection of Hotspot Shield over UDP and

TCP.
97
Enhancements
Release 11.0.R14
IPsec
Two new traps have been introduced for IPsec static and GRE/IP-in-IP tunnels to indicate
tunnel operational state changes. Currently, such events are recorded in tmnxStateChange;
in addition to the new traps, the system will continue to include the events in
tmnxStateChange. Note that the capability to use tmnxStateChange to track the tunnel
operational state is being deprecated and will be removed in a future release. [190978]
Application
Assurance
Protocol
Status
Comments
JustinTv
updated
Provides detection of only Twitch Video Streaming

(both services belong to the same parent company,
Twitch Interactive)
Release 11.0.R13
A new log event and SNMP notification have been added to monitor if an MDA exhibits
persistent ingress XPL errors, which are FCS errors in the header of the cells transmitted
between an MDA and its IOM. An error threshold can be provisioned under
config>card>mda>ingress-xpl, and if fail-on-error is configured on the MDA, the latter
can be disabled when the threshold is reached. This enhancement enables fail-on-error for
all MDA types and expands enhancement 159196 also for Ethernet MDAs. Ingress XPL
error detection applies only to the following IOM/IMM types: iom3-xp, iom3-xp-b, iom3xp-c, imm48-1gb-tx, imm48-1gb-sfp, imm48-1gb-sfp-b, imm48-1gb-sfp-c, imm4-10gbxfp, imm8-10gb-xfp, imm5-10gb-xfp, imm1-oc768-tun, imm1-40gb-tun.[176689]
The optional parameter exclude-sfm has been added to the show system switch-fabric
command to preview the impact of removing an SFM so that the operator can determine in
advance if there will be reduced traffic throughput capacity. [182632]
Routing
In Release 11.0.R13, a new interface option has been added to allow for the configuration
of the ARP retry frequency. Prior to Release 11.0.R13, the ARP retry interval was set at a
static five (5) second interval. With the new command arp-retry-timer, the retry interval
can be set to a value within the range of 100 ms to 30,000 ms. Note that setting an
aggressive retry interval can increase CPU utilization. [186241]
EPIPE/VPLS
The configuration of QinQ pseudowires (PW) has been added in Epipe and VPLS services,
which allows for the ability to add and remove two VLAN tags to and from the PW.
Specifically, two VLAN tags will be pushed onto traffic sent on a QinQ PW, and up to two
HW/Platform
98
Enhancements
VLAN tags will be popped from traffic received on a QinQ PW. These actions are enabled
using the force-qinq-vc-forwarding parameter under the spoke or mesh SDP or in a PWtemplate configuration, with the latter providing the support for BGP VPLS and BGP
VPWS services, and LDP VPLS services using BGP Auto-Discovery.
Support has also been added for the configuration of 802.1ag (MIP and MEP) on a BGP
VPWS SAP (Epipe only). Fault propagation between a MEP and the BGP update state signaling is not supported.
This set of enhancements is supported only when all network interfaces are configured on
FP2- and higher-based line cards; there are no restrictions for this feature with respect to
the hardware used for any associated SAPs. Refer to Known Limitations on page 183 for
restrictions that apply. [181110]
Application
Assurance
Protocol
Status
Comments
Ultrasurf
new
Provides the detection of Ultrasurf over SSL
CCcam
updated
Provides improved detection of encrypted CCcam

flows over TCP
HTTP Video
updated
Provides the detection of the F4V file extension
QQ
updated
Provides improved detection of QQ over UDP
SoulSeek
updated
Provides improved detection of SoulSeek over TCP
Release 11.0.R12
System
Release 11.0.R12 introduces the capability of configuring two cipher lists for client/server
negotiation of the best compatible ciphers between the two. The two cipher lists can be
created and managed under the configure system security ssh CLI context. The clientcipher-list is used when the SR OS node is acting as the SSH client, and the server-cipherlist is used when the SR OS node is acting as a server. The first cipher matched on the list
between the client and server is the preferred cipher for the session. [173801]
LAG
In Release 11.0.R12, the efficiency of packet load-balancing is improved in two cases

when both ECMP and LAG hashing are performed on a LER or LSR: when the number of
LAG links are in the ranges 17-31 or 33-63 for any number of ECMP tunnel next-hops, or
when the number of ECMP IP next-hops are in the range 17-31 for any number of LAG
links per IP interface. The chassis must be in mode D, which is required to increase ECMP
or LAG links to more than 16. [180238]
99
Enhancements
BGP
Release 11.0.R12 introduces the option to ignore the router ID in the BGP best-path
selection algorithm used to compare mVPN routes. By ignoring the router ID, unnecessary
route churns can be avoided when there are many mVPN routes with NLRIs that differ
only in the router ID of the advertising router. The disable-route-table-install command
will now automatically apply to mvpn-ipv4 and mvpn-ipv6 routes when these address
families are present (previously, only IPv4 and IPv6 address families were considered),
which can improve mVPN route convergence time on control-plane route reflectors.
[175404]
Application
Assurance
OAM
100
Protocol
Status
Comments
Newcamd
new
Provides the detection of the satellite card sharing

protocol newcamd
CNN Live
updated
Provides improved detection of CNN Live over

RTMP
Funshion
updated
Provides improved detection of Funshion streaming

video over UDP
PPStream
updated
Provides improved detection of PPStream video

streaming over UDP
QQ
updated
Provides improved detection of QQ picture uploading over TCP
QQ
updated
Provides improved detection of QQ video/audio

communication between two QQ devices over TCP
SOCKS
updated
Provides improved detection of SOCKS in the situation where the UDP traffic starts late
Weixin
updated
Provides detection of WeChat file transfers over

TCP which were being detected as HTTP
In Release 11.0.R12, ETH-AIS can now be configured to ignore the CCM defect RDI as a
trigger for the generation of AIS. [173813]
Enhancements
Release 11.0.R11
Release 11.0.R10
Protocols with short timers (i.e., BFD and ETH-OAM) can, in rare cases, bounce due to
certain automatic recovery actions in the data path. Release 11.0.R10 provides a new log
event (tmnxEqDataPathFailureProtImpact) that will be generated if such an event occurs.
[161774]
IEEE 1588 Port-Based Timestamping capability is now supported on the 7750 SR-12e
platform. [179550]
BGP
Release 11.0.R10 adds the support for the Control Word for BGP VPWS services. Prior to
Release 11.0.R10, the configuration of the Control Word within the pw-template was
ignored for BGP VPWS services. [179147]
LDP
Release 11.0.R10 adds the support for configuring a limit on the number of LDP FECs that
an LSR will accept from a given peer and add into the LDP label database. Once the limit is
reached, any new FEC received will be released back to the peer.
HW/Platform
Once a FEC is released, the peer will automatically replay the released FEC when the
threshold is crossed downwards if the peer is SR OS-based and implements the LDP overload status TLV. If a peer is a third-party implementation, a manual replay of the FEC by
the peer or operationally toggling the LDP session may be required. [178414]
IP Multicast
PIM
Release 11.0.R10 allows operators to enable KeepAlive Timers (KAT) on source PEs for
NG-mVPN inter-site shared deployments (config>service>vprn>mvpn>intersite-shared
kat-type5-adv-withdraw). On a multicast source failure, a KAT expiry on source PEs will
trigger a withdraw of Type-5 Source-Active (S-A) route and switch from (C-S,C-G) to (C*,C-G). When receiver PEs process reflected Type-5 S-A route withdrawals, they will
withdraw their Type-7 NG-mVPN routes to the failed multicast source. Note the following:
-
KAT must only be enabled on source PEs
Functionality is supported with mLDP and RSVP-TE in the provider mVPN instance
Local receiver per (C-S,C-G) must be configured on source PEs running KAT
As multicast converges, a duplication of traffic may take place if a failed multicast

source comes back up and starts sending traffic again. [172994]
Release 11.0.R10 changes processing of PIM Join/Prune messages with multiple multicast
groups when a message contains invalid local-scope multicast addresses. Prior to this
enhancement, a Join/Prune processing was stopped when the first invalid local-scope
address was found in a message. The enhanced processing of PIM Join/Prune message will
skip over an invalid local-scope multicast address and will continue to process the valid
Joins/Prunes in the same message. [183091]
101
Enhancements
Application
Assurance
Protocol
Status
Comments
Advanced Direct Connect
new
Provides the detection of Advanced Direct Connect

traffic over TCP and UDP
Blackberry Messenger
new
Provides the detection of BBM Voice/Video over

RTP and BBM Instant Messaging and Channels
over TLS
PCoIP
new
Provides the detection of PC-over-IP (PCoIP) data

traffic over UDP, and control traffic over TLS
FTP
updated
Provides improved detection of FTP over TCP
Funshion
updated
Provides improved detection of Funshion over TCP

and UDP
OpenVPN
updated
Resolves the issue where BFD traffic was being

detected as OpenVPN
Release 11.0.R9
PPPoE
In Release 11.0.R9, PPPoE/PPPoA/PPPoEoA CHAP Response with no Name field and

PAP Authenticate-Request with no Peer-Id field (Peer-Id-Length=0) is allowed with the
default-user-name user-name CLI parameter in the ppp-policy. In this case, the empty PPP
username is replaced with the configured default user-name string. The PPP session
terminates when no default user name is configured and the client provides no user name in
the Authenticate-Request or CHAP Response.
Furthermore, a default PAP password can be specified for PPPoE/PPPoA/PPPoEoA PAP
Authenticate-Request with no Password field (Passwd-Length=0). In this case, the empty
PAP password is replaced with the default-pap-password password configured in the ppppolicy. RADIUS authentication fails when no default PAP password is configured and the
client provides no password in the Authenticate-Request. [177343]
Application
Assurance
Release 11.0.R9 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
shown in the table below. For a complete list of the Release 11.0 AA identification
102
Protocol
Status
Comments
CCcam
new
Provides detection of CCcam satellite card sharing

over TCP
Enhancements

HTTP
updated
Provides improved detection of HTTP when the

first payload packet is out of sequence
HTTP Video
updated
Provides improved detection of HTTP video traffic

that was being classified as HTTP
Microsoft SQL
updated
Provides improved detection of Microsoft SQL

over TCP
ooVoo
updated
Provides improved detection of audio and video

traffic over UDP
PPLive
updated
Resolves the issue of some PPStream traffic being

classified as PPLive
Viber
updated
Provides improved detection of Viber over TCP
Viber
updated
Provides improved detection of Viber AudioCall

traffic over UDP
Release 11.0.R8
HW/Platform
In Release 11.0.R8, an object has been added to the tmnxHwEntry table to indicate the
device's firmware/FPGA revision status, which can have the following values:
-
Not Applicable
Acceptable
Not acceptable
Will be upgraded
Is upgrading [156833]
Release 11.0.R8 introduces a new alarm when defective SFPs are inserted and the
transceiver data cannot be read. [173082]
System
Two CLI commands, show system cpu and show system memory-pools, have been
enhanced. The output of those commands was changed: PIM label was replaced with
PIM/L2Mcast label to better reflect that the CPU utilization reported against this label
applies to PIM and L2 Multicast-related tasks. The same change was also implemented in
the SNMP interface by modifying tmnxSysCpuMonBusyGroupName and
tmnxCardCpuResMonBusyGroupName in TIMETRA-SYSTEM-MIB. [127594]
IPsec
Release 11.0.R8 introduce a stateless inter-chassis redundancy solution for IKEv1. Being
stateless means that IKEv1 tunnel states are not synchronized between chassis. However,
MIMP/shunting/route-tracking will function for IKEv1 tunnels. [172615]
In Release 11.0.R8, for a given IPsec public/private interface, if the associated tunnelgroup is MC-IPsec standby and static/dynamic-tunnel-redundant-next-hop is configured,
then shunt is now appended to the interface route in the output of show route rt-id routetable. [174516]
103
Enhancements
Release 11.0.R8 adds the timestamp of the last operation status change for IP tunnel and
IPsec tunnel. [174890]
ASAP
Release 11.0.R8 introduces the support for 56 kb/s DS0 and n*DS0 channel speeds on the
ASAP TDM MDA family. 56 kb/s channel speed is capable on all ASAP-supported
encapsulations except for ATM. All DS0 channels within a given DS3 port/channel must
be configured for the same channel speed: 56 kb/s or 64 kb/s. 56 kb/s channels cannot be a
part of bundles. 56 kb/s is only supported on the m4-chds3-as and m12-chds3-as MDAs on
DS1 channels (ESF and SF framing), but not on E-1 (G.704) channels. [166987]
PPPoE
When unique-sid-per-sap is enabled in the ppp-policy, the number of PPPoE sessions

with unique session-id on a given SAP is increased from 1023 to 8191. [171365]
The maximum number of PPP sessions with the same MAC address (max-sessions-permac) has been increased from 1023 to 8191. [173081]
The HTTP-notification flow selection for HTTP In-Browser-Notification has been

enhanced to support additional types of HTTP flows. [168109]
Application
Assurance
104
Protocol
Status
Comments
LINE
new
Provides detection of LINE voice/video over UDP

and LINE instant messaging over TLS
Tango
new
Provides detection of Tango Voice and Video over

TCP/UDP, Tango Instant Messaging and Photo
Sharing over TLS and Tango Emoticon, Animations, and Game Downloads over HTTP
Betamax VoIP
updated
Provides improved detection of Betamax Audio

over SIP RTP
eMule
updated
Provides detection of encrypted eMule traffic over

TCP and UDP
RTP
updated
Provides improved detection of RTP when interleaved with STUN/TURN traffic
SIP
updated
Provides improved detection SIP traffic over RTP
SIP
updated
Provides improved detection of SIP and RTP_SIP

over TLS
Steam
updated
Resolves the issue of Fetion traffic being detected

as Steam
STUN
updated
Provides improved detection of STUN as outlined

in RFC 538
STUN
updated
Resolves an unlikely issue of STUN being detected

as GTP
Enhancements

uTP
updated
Provides improved detection of uTP traffic which

was being detected as DHT
Yahoo Messenger
updated
Provides improved detection of Yahoo Messenger

over TCP
Release 11.0.R7
HW/Platform
A mechanism has been implemented for the active CPM to test its own connectivity to the
switch fabric and to reset if a loss of connectivity has been detected, resulting in a HighAvailability switchover in cases where a standby CPM is present. [168897]
IPsec
A new CLI command always-set-sender-for-ir under config>system>security>pki>caprofile>cmpv2 has been introduced in Release 11.0.R7 to always set the sender field in
the CMPv2 header of the Initialization Request (IR). Without this command, the system
will set the sender of IR only when a certificate is included in the extraCerts field. [169426]
Management
Release 11.0.R7 includes the following changes to the ingress statistics in the TIMETRAVRTR-MIB:
-
vRtrIfRxPkts and vRtrIfRxBytesThese counters now reflect an aggregate count of

both IPv4 and IPv6 packets
vRtrIfuRPFCheckFailPkts and vRtrIfuRPFCheckFailBytesThese counters now

reflect an aggregate count of both IPv4 and IPv6 packets
Application
Assurance
New IPv4-only versions of the following counters have been added:

-
vRtrIfRxV4Pkts and vRtrIfRxV4Bytes
vRtrIfV4uRPFCheckFailPkts and vRtrIfV4uRPFCheckFailBytes. [167809]
Protocol
Status
Comments
RTSP
updated
Provides improved detection of RTSP streaming

over UDP
SIP
updated
Provides improved detection of SIP over RTP
105
Enhancements
Release 11.0.R6
An alarm has been added to show when an AC rectifier has failed or been removed.
[116391]
In Release 11.0.R6, the XPL bus between IOM and MDA is now monitored on ATM and
SONET MDAs and a tmnxEqMdaXplError event/trap is generated when errors occur. This
functionality already existed for ASAP MDAs in Release 11.0.R2. [145410]
The new Alcatel-Lucent 10Gbps DWDM Tunable High Power SFP+ optical transceiver
supports 10Gbps Ethernet, allowing the router to be configured to utilize any of the 89
supported channels in the DWDM C-band grid. The following card types are supported in
Release 11.0.R6: imm12-10gb-xp-sf+, imm-2pac-fp3/p6-10g-sfp/p6-10g-sfp and imm2pac-sfp/p10-10g-sfp/p10-10g-sfp. [150816]
In Release 11.0.R6, a tmnxEqCardTChipParityEvent event will be generated for

recoverable memory errors on the switch fabric interface of IOM/IMM cards. This event is
suppressed by default but can be enabled in configuration. Automatic card reset for nonrecoverable fabric interface memory errors was already implemented in an earlier release.
[153835]
Software enhancements have been made to cause an MDA to fail (thus triggering an APS
fail-over or traffic re-route) if the MDA is experiencing too many egress XPL errors. This
behavior can be enabled or disabled by the user on ASAP, ATM, and SONET MDAs.
[159196]
A tmnxEqPowerSupplyInputFeedAlm event/trap is now generated for the 7950 XRS when

any of the input feeds for a given power supply no longer supplies power. Correspondingly,
there is a tmnxEqPowerSupplyInputFeedAlmClr event/trap when the condition is cleared.
[167841]
System
The support for the keyboard-interactive authentication method, as specified in RFC 4256,
has been added to the SR OS SSH server. If the SR OS SSH server has interactive
TACACS+ authentication enabled (configure system security tacplus interactiveauthentication), it will include the keyboard-interactive as one of the authentication
methods in the name-list of the response. Keyboard-interactive capability, along with
TACACS+ interactive-authentication, supports the use of One Time Password schemes
(e.g., S/Key) with SSH.
LAG
Release 11.0.R6 improves the LAG spraying of Apipe, Cpipe, Epipe, Ipipe, and Fpipe
service packets when both ECMP and LAG hashing are performed by the same router. By
default, the ECMP interface and LAG link for all packets on these services are selected
based on a direct modulo operation of the service ID. Release 11.0.R6 introduces an
enhanced distribution which hashes the service ID prior to the LAG link modulo operation.
[159489]
Release 11.0.R6 enhances per-link-hashing and LAG link mapping profiles features by
adding the support for NG-mVPN with mLDP core.
Starting with Release 11.0.R6, a new max-metric option has been added to the
config>router>isis>overload command to advertise transit links with the maximum
HW/Platform
IS-IS
106
Enhancements
metric of 0xffffff for wide metric (0x3f for regular metric) instead of setting the overload
bit when placing the router in overload state. [150037]
Starting with Release 11.0.R6, the user can now configure a router-id value in each instance
of IS-IS, including the default instance. By default, the global value of router-id
(config>router>router-id) is used when an IS-IS instance is created. The IS-IS system ID
for the instance continues to be derived from the router-id. [150880]
In Release 11.0.R6, a new IS-IS command, ignore-lsp-errors, has been added to change the
handling of LSP errors. When the command has been issued, IS-IS LSP errors will be
ignored and will not result in the purging of the associated record. [159233]
DHCP
Starting in Release 11.0.R6, the following On-Demand Subnet Allocation (ODSA)

bind/unbind events are generated by a 7750 SR-based DHCPv4 server: subnet binding
created, subnet binding unbind-delay started and subnet binding deleted. [166389]
QoS
Self-Generated Traffic Quality of Service (sgt-qos) for RADIUS has been enhanced to
allow the control of the sgt-qos setting for RADIUS-based protocols, independent of the
configured destination ports. Prior to Release 11.0.R6, only well-known destination ports
were considered. [164829]
WiFi Offload and

Aggregation
Release 11.0.R6 supports GGSNs/PGWs returning a different IP address in the sessioncreate response than the original IP address used for the GGSN/PGW in the session-create
request from the WLAN-GW. Subsequent session and path management messages will be
directed to the updated IP address. [166923]
Application
Assurance
Protocol
Status
Comments
Microsoft Lync
new
Provides the detection of Microsoft Lync Desktop

Sharing and File Transfer over TCP, Conferencing,
Control and Application Sharing over TLS and
Audio/Video over RTP
AOL Instant Messenger
updated
Provides improved detection of AOL Instance Messenger voice and video chat traffic over TCP and
UDP
Ares
updated
Provides improved detection of Ares over UDP
BBC iPlayer
updated
Provides improved detection of BBC iPlayer over

RTMP
QQ
updated
Provides improved detection of QQ, including web

video chat and file transfers
SoulSeek
updated
Provides improved detection of SoulSeek over TCP
Steam
updated
Provides improved detection of Steam over TCP
107
Enhancements

TeamSpeak
updated
Provides improved detection of TeamSpeak over

TCP and UDP
WeChat
updated
Provides improved detection of WeChat over TCP

and HTTP
Release 11.0.R5
HW/Platform
A new show router fp-tunnel-table slot=1 [prefix] command is introduced in Release

11.0.R5 to provide the IOM/IMM/XCM label, next-hop, and outgoing interface
information for BGP, LDP, and RSVP tunnels used in any of the following applications:
-
BGP shortcut (configure>router>bgp>igp-shortcut)
IGP shortcut (config>router>isis[ospf]>rsvp-shortcut)
IGP prefix resolved to an LDP LSP (config>router>ldp-shortcut)
Static prefix shortcut
VPRN auto-bind
6PE/6VPE. [148677]
An admin tech-support file can now optionally have an automatic SR OS-generated file
name based on the system name and the date/time. A new ts-location must first be
configured in order to use the automatic tech-support file-naming enhancement. The fileurl parameter of the tech-support file is now optional. [130062]
Release 11.0.R5 adds the support for additional characters as part of the log-prefix string.
[161438]
Release 11.0.R5 enables the support for hold-time down on Ethernet ports that are part of
LAGs. [161778]
Release 11.0.R1 and 11.0.R4 introduced LAG per-link-hashing and LAG link mapping
profiles. Release 11.0.R5 enhances these features by adding the support for LAGs with
multiple sub-groups configured.
IP Multicast
Release 11.0.R5 adds the Loop Free Alternate (LFA) support to Multicast-only FastReroute (MoFRR).
PIM
Release 11.0.R5 enhances Draft-Rosen mVPN Inter-AS support. Some Cisco

implementations use Core RPF vector encoding instead of RFC-compliant mVPN RPF
vector encoding for Inter-AS option B/C. To allow interoperability with those
implementations, SR OS now allows the operator to configure the use of Core RPF vector
instead of, or in addition to, mVPN RPF vector.
CLI
LAG
108
Enhancements
Management
Release 11.0.R5 adds the support for incrementing packet counters in the ifTable and
ifXTable in the IF-MIB based on the aggregate forwarded traffic on a network IP interface.
The following counters are incremented:
IPsec
ifXEntry
ifHCInOctets
ifHCInUcastPkts
ifHCOutOctets
ifHCOutUcastPkts
ifEntry
ifInOctets
ifInUcastPkts
ifInDiscards
ifOutOctets
ifOutUcastPkts
ifOutDiscards. [146878]
Release 11.0.R5 supports the verification of X.509v3 certificate with the following
additional signature algorithms:
-
sha224WithRSAEncryption
sha512WithRSAEncryption.
The command admin certificate gen-local-cert-req has also been enhanced to support
generating certificate-requests with the above algorithms as follows:
admin certificate gen-local-cert-req keypair url-string [hash-alg
{sha1|sha224|sha256|sha384|sha512}] subject-dn subject-dn [domain-name [255
chars max]] [ip-addr ip-address] file url-string. [147695]
The system will now only generate /32 local IPsec gateway address route for tunnels that
belong to a MC-IPsec-enabled tunnel-group. [162463]
Filter Policies
IPv6 line card filter policy functionality has been enhanced to allow the match on
presence/absence of IPv6 AH and ESP Extension Headers. [160938]
BGP
Release 11.0.R5 introduces a new configuration option to not modify the BGP next-hop
when sending label-IPv4 routes to selected BGP peers. [151997]
Release 11.0.R5 provides a new configuration option to allow IP-VPN routes imported into
a VPRN to be re-exported again as new IP-VPN routes that appear as though they were
originated by the VPRN. This option can be useful in some data center interconnection
scenarios. [157077]
109
Enhancements
Subscriber
Management
New macro substitutions have been defined to include Relay Agent Circuit-id / Interface
ID and Relay Agent Remote-id in the redirect URL for IPv4 and IPv6 HTTP-redirect
filters. [155973]
ECMP load-balancing to identical RADIUS Framed-Routes/Framed-IPv6-Routes with a

different next-hop is now supported. Prior to Release 11.0.R5, only one of the identical
Framed-Routes/Framed-IPv6-Routes was installed in the routing table independent of the
configured ecmp max-ecmp-routes. [156828]
Framed-Route and Framed-IPv6-Route metrics (metric, tag and preference) are now also
reported in the Framed-Route and Framed-IPv6-Route attributes in RADIUS Accounting
messages. [158890]
The maximum number of lease states with DHCP relay has been increased. The MSAP and
subscriber-ID limits remain the same. [162385, 164208]
Release 11.0.R5 adds the support for configuring a system-wide subscriber-management

next-hop limit. This can be configured via the configure subscriber-mgmt next-hop-limit
<[0..16383]> command. Note that this only counts/limits the number of ip-next-hops
consumed via subscriber-management managed routes. It does not count ip-next-hops
consumed by any other protocol.
A new event-log tmnxSubSysNextHopUsageHi has been added to indicate when the limit
has been reached. The default value of the limit is set to the total number available nexthops. [164034]
Starting from Release 11.0.R5, RADIUS-proxy can be enabled simultaneously with the
CoA port configured to 1812. CoA messages will no longer be dropped in this case.
[165349]
MPLS
Release 11.0.R5 introduces a new CLI command to allow MPLS in the ingress LER to
immediately tear down and re-signal all LSP paths away from a transit LSR node which
advertised the IS-IS overload bit. By default, MPLS will re-optimize using make-beforebreak (MBB) the paths away from the node in IS-IS overload state at the time a manual or
timer-based re-signal is performed. LSP paths that terminate on the node that advertised the
IS-IS overload bit are not impacted in any of these cases. [150328]
MPLS-TP
Release 11.0.R5 adds the ability for LSP-ping and LSP-trace on MPLS-TP LSPs to use the
IPv4 Generic Associated Channel. [161057]
Release 11.0.R5 adds the support for the following MPLS-TP functionality:
Application
Assurance
110
Control Channel Status Request mechanism This optional mechanism enhances

the RFC 6478 behavior of control channel status signaling to allow a PE to request the
current pseudowire (PW) status from a peer PE for a PW with static labels
Control Channel Status Acknowledgement.
Enhancements
OAM
Protocol
Status
Comments
Amazon Audio/Video
new
Provides detection of Amazon streaming

audio/video over RTMPE, RTMPT, HTTP and TLS
Vine
new
Provides detection of Vine over TLS
Headcall
updated
Provides improved detection of Headcall over UDP
JustinTv
updated
Provides improved detection of JustinTv IRC traffic over TCP and JustinTv audio/video streaming
over RTMP
RTMP Streaming
updated
Provides improved detection of RTMP streaming

video over UDP
SIP
updated
Provides improved detection of Vonage services

over SIP
Subversion
updated
Provides improved detection of Subversion over

HTTP
TLS
updated
Provides improved detection of TLS for asymmetrical flows
LDP-treetrace and LSP-trace with the path-destination option enabled are now supported
on an LDP FEC that is tunneled over an RSVP LSP (LDP-over-RSVP tunnel). The user
must enable the use of the new DDMAP TLV either globally (config>test-oam>mplsecho-request-downstream-map ddmap) or within the specific ldp-treetrace or lsp-trace test
(downstream-map-tlv ddmap). [73650, 155490]
LDP-treetrace and LSP-trace with the path-destination option enabled are now supported
on an LDP FEC that is stitched to a BGP labeled route. The user must enable the use of the
new DDMAP TLV either globally (config>test-oam>mpls-echo-request-downstream-map
ddmap) or within the specific ldp-treetrace or lsp-trace test (downstream-map-tlv
ddmap). [105364, 155490]
ETH-CFM MEPs now support the reception and processing of Ethernet Customer Signal
Failure (ETH-CSF) as a trigger for fault propagation. Transmissions of ETH-CSF frames
are not supported. [152308]
Release 11.0.R4
HW/Platform
Release 11.0.R4 introduces a new alarm for P-Chip memory errors that occur on the
SF/CPM hardware such that the administrator is notified when a P-Chip memory error rate
has exceeded its threshold. In addition to the optional log message and SNMP trap, the
timestamp of the last occurrence of the event and number of times the threshold was
crossed can now be seen in the show card detail command. [135545]
The following APEQ status LED changes have been made in Release 11.0.R4:
111
Enhancements
Blue for booting
Blinking blue while waiting for enough other APEQs to start powering on cards
Amber for fault
Flashing red if there are no fan trays
Blinking green if no CPU signal has been received
Solid green for Everything has powered up, and no internal faults were detected.
A solid or blinking blue light indicates startup mode while green lights are only used while
in operation.
In addition, for the 7750 SR-12e and 7950 XRS-16c/20, the number of APEQs required for
the system to power on will now be three (3) APEQs (four (4) APEQs prior to Release
10.0.R12). Three APEQs will now be the new level in which the APEQ status LED will go
from a flashing blue to a flashing green. [156260]
Blue: has power and is performing self test
Green (solid): Normal operation
Green (blinking): Local control
Amber (solid): Recognized fan fault has occurred
Off: Safe to remove fan tray [156478]
The system will now generate events for queue buffer memory errors, queue statistics
memory errors and Q-Chip internal memory errors detected on a line card. The line card
will be disabled to state failed upon the first event if fail-on-error is enabled for that card.
[157905]
The SR OS boot process can be interrupted in the boot.ldr by any key press received on the
console port. In Release 11.0.R4, the boot process will now automatically continue after it
has been interrupted unless a specific sequence of characters (sros and [enter]) is typed
by the operator before a 30 second timer expires. This ensures that the boot process will
automatically continue if it was unintentionally interrupted by noise, misconfiguration or
operator error. [134535]
The NTP time recovery process has been augmented to smoothly incorporate leap second
events.
NTP
In Release 11.0.R4, the number of NTP servers and NTP peers allowed has been increased
from five (5) to ten (10). [148924]
Filter
Release 11.0.R4 adds new IPv6 extension header existence/absence match criteria to CPM
and IOM IPv6 filter policies for FP2- and FP3-based IOMs/IMMs/XMAs and C-XMAs on
7750 SR, 7750 SR-c12, 7450 ESS in mixed-mode, and 7950 XRS platforms. The new
match criteria include existence/absence of fragmentation extension header (CPM filter
policies), match on the initial or non-initial fragments only (line card filter policies)
existence/absence of routing extension header type 0 (line card filter policies), and
existence/absence of hop-by-hop options extension header (CPM and line card filter
System
112
On the XRS-20, the Fan Status LED has the following new behavior starting with Release
11.0.R4:
Enhancements
policies). The existing behavior prior to Release 11.0.R4 is preserved with the default no
configuration for each new option. [129167]
The debug ipsec command has been enhanced in Release 11.0.R4 to include decoded
output for all ingress/egress IKE packets, along with a new nat-ip parameter for the
debug ipsec gateway command, which specifies the inside IP address and port of the
peer. [157457]
Release 11.0.R4 allows up to 16 tunnel interfaces created in a VRF for LAN-to-LAN IPsec
tunnels. [160924]
The CLI command show lag lag-id lacp-partner [detail] has been added to display
information about the LACP partner: port-id, port-priority, port-key, port-state. Previously,
these information were only available via SNMP as part of the IEEE8023-LAG-MIB.
[151502-MI]
Release 11.0.R1 introduced LAG per-link-hashing. Release 11.0.R4 enhances this feature
by adding the support for NG-mVPN with RSVP-TE provider tunnels, ESM, PW port, and
SAPs for L2 services on a LAG with per-link-hashing enabled.
Release 11.0.R1 introduced LAG link mapping profiles. Release 11.0.R4 enhances this
feature by adding the support for VPRN SAPs, network interfaces, ng-mVPN with RSVPTE provider tunnels, ESM, PW port, and SAPs for L2 services.
Release 11.0.R1 introduced support for a new LAG adapt-qos mode: distributed includeegr-hash-cfg. Release 11.0.R4 extends this new mode with the above-described extensions
to LAG link mapping profiles and LAG per-link hashing.
Management
The log event-throttling rate can now be configured independently for each log event using
a new specific-throttle-rate keyword. This specific-throttle-rate overrides the globally
configured throttle rate (configure log throttle-rate) for the specific log event. [152803]
DHCP
In a scaled setup with local-dhcp-server fail-over protection configured, putting a node that
was previously isolated or in partnerDown state into service after all local leases and
MCS states were cleared might have resulted in incorrectly denied or timed-out leases. The
reason was that the local-dhcp-server could transition from partnerDown to Normal
state before all MCS data was synchronized. Starting with Release 11.0.R4, the node will
first transition to a pre-Normal state for a time equal to the Maximum Client Lead Time
(MCLT) or until MCS data synchronization is complete. In pre-Normal state, a node will
not reply to any RENEWS or REBINDS for which it has no local data available in MCS.
The remote node also will not transition anymore from partnerDown to Normal state
directly, but will also stay in a pre-Normal state for a time equal to the Maximum Client
Lead Time (MCLT) or until MCS data synchronization is complete. In this pre-normal
state, the remote node will keep replying to RENEWS and REBINDS if fail-over (FO)
control remote is set. New leases (DHCPDiscover) will only get offered an address from
the local FO subnet. [150649]
BGP
Release 11.0.R4 introduces the support for the BGP split-horizon command at the BGP
instance and group-configuration levels. [146781]
IPsec
LAG
113
Enhancements
MPLS
LDP
Release 11.0.R4 adds a BGP command to change the type encoding of the VRF route
import extended community used by NG-mVPN services to the IANA-compliant value.
[154219]
Release 11.0.R4 introduces a new MPLS auto-bandwidth command that allows more
control over how the byte counts for the different forwarding classes are counted towards
the average data rate of each sample interval. In releases prior to Release 11.0.R4, the
average data rate was based on a simple sum of the traffic from all eight (8) forwarding
classes; with this enhancement, it can be derived from a weighted sum. [137084]
Auto-Bandwidth Make-Before-Break (MBB) now supports up to five (5) retry attempts to

re-optimize the path of an LSP to the new operational bandwidth. [147198]
A new pe-id-mac-flush-interop flag has been added. This flag enables the addition of the
PE-ID TLV in the LDP MAC withdrawal (MAC-flush) message, under certain conditions,
and modifies the MAC-flush behavior for interoperability with other vendors devices that
do not support the flush-all-from-me vendor-specific TLV. This flag can be enabled on a
per-LDP-peer basis and allows the flush-all-from-me interoperability with other vendors
devices. When the pe-id-mac-flush-interop flag is enabled for a given peer, the current
MAC-flush behavior is modified in terms of MAC-flush generation, MAC-flush
propagation and behavior upon receiving a MAC-flush.
The MAC-flush generation will be changed depending on the type of event and according
to the following rules:
-
Any all-from-me MAC-flush event will trigger a MAC-flush all-but-mine message

(RFC-4762-compliant format) with the addition of a PE-ID TLV. The PE-ID TLV
contains the IP address of the sending PE.
Any all-but-mine MAC-flush event will trigger a MAC-flush all-but-mine message

without the addition of the PE-ID TLV as long as the source spoke-SDP is not part of
an endpoint.
Any all-but-mine MAC-flush event will trigger a MAC-flush all-but-mine message

with the addition of the PE-ID TLV if the source spoke-SDP is part of an endpoint
and the spoke-SDP goes from the down/standby state to the active state. In this case,
the PE-ID TLV will contain the IP address of the PE to which the previous active
spoke-SDP was connected.
Any other case will follow the existing MAC-flush procedures. When the pe-id-MACflush-interop flag is enabled for a given LDP peer, the MAC-flush ingress processing is
modified according to the following rules:
-
Any received all-from-me MAC-flush will follow the existing MAC-flush all-fromme rules regardless of the existence of the PE-ID.
Any received all-but-mine MAC-flush will take into account the received PE-ID (i.e.,
all MAC addresses associated with the PE-ID will be flushed. If the PE-ID is not
included, the MAC addresses associated with the sending PE will be flushed).
Any other case will follow the existing MAC-flush procedures. When a MAC-flush message has to be propagated (for an ingress SDP-binding to an egress SDP-binding) and the
pe-id-mac-flush-interop flag is enabled for the ingress and egress T-LDP peers, the following behavior is observed:
114
Enhancements
If the ingress and egress bindings are spoke-SDP, the PE will propagate the MACflush message with its own PE-ID.
If the ingress binding is a spoke-SDP and the egress binding a mesh-SDP, the PE will
propagate the MAC-flush message without modifying the PE-ID included in the PEID TLV.
If the ingress binding is a mesh-SDP and the egress binding an spoke-SDP, the PE
will propagate the MAC-flush message with its own PE-ID.
When ingress and egress bindings are mesh-SDP, the MAC-flush message is never
propagated. This is the behavior regardless of the pe-id-mac-flush-interop flag
configuration.
Note that the PE-ID TLV is never added when generating a MAC-flush message on a BVPLS if the send-bvpls-flush command is enabled in the I-VPLS. In the same way, no PEID is added when propagating MAC-flush from a B-VPLS to a I-VPLS when the propagate-mac-flush-from-bvpls command is enabled. MAC-flush messages for peers within the
same I-VPLS or within the same B-VPLS domain follow the procedures described above.
[155577]
PIM
With protocol-protection enabled, PIM in an mVPN on the egress DR was not switching
traffic from the (*,G) to the (S,G) tree. That behavior has been corrected and a new optional
keyword (block-pim-tunneled) has been added to protocol-protection configuration that
allows an operator to optionally block extraction and processing of PIM packets arriving at
the SR OS node inside a tunnel (e.g., MPLS or GRE) on a network interface. [150674]
QoS
Release 11.0.R4 adds the ability to override the following policer control policy parameters
for access, as well as network ingress forwarding-plane queue groups:
policer-control-override [create]
no policer-control-override
max-rate {<rate> | max}
priority-mbs-thresholds
min-thresh-separation <size> [bytes | kilobytes]
no min-thresh-separation
[no] priority <level>
mbs-contribution <size> [bytes | kilobytes]
no mbs-contribution
The user can also override the policer parameters for network ingress FP queue groups.
The following parameters for policers can be overridden:
config>card>fp>ingress>network>qgrp>policer-over>plcr$
[no] cbs
Specify CBS override
[no] mbs
Specify MBS override
[no] packet-byte-of*
Specify packet byte offset
[no] rate
Specify rates (CIR and PIR) override
[no] stat-mode
Specify Stat Mode for the policer [147910]
Starting with Release 11.0.R4, it is now possible to tune the responsiveness of the virtual
scheduler for a set of queues using the QoS virtual-scheduler-adjustment policy on Q1
chip-based line cards. To achieve the best reaction time result, the total (combined ingress
and egress) number of queues on the line card should be limited to 1000. [150263]
115
Enhancements
IP-MTU enforcement on regular group-interfaces is now supported in Release 11.0.R4

with the ip-mtu CLI command in the group-interface context
(config>service>ies|vprn>sub-if>grp-if). This applies to all IPoE host types (DHCP,
ARP, static). For PPP/L2TP sessions, the ip-mtu on group-interfaces is not taken into
account for the MTU negotiation; the ppp-mtu in the ppp-policy should be used instead.
[105360]
For a PPPoE session, a new RADIUS attribute [26-6527-181] Alc-SLAAC-IPv4-Pool

passes the name of a SLAAC pool for the subscriber to use during the authentication
process. The SLAAC pool utilizes the same pools as the DHCPv6 configuration accessed
in the local-address-assignments IPv6 client-application ppp-slaac. The SLAAC pool
delegates a unique /64 prefix to the subscriber and no other subscriber is allowed to reuse
the /64 prefix. Upon termination of the PPPoE session, the prefix is returned to the SLAAC
pool. [147085]
PCP for DS-Lite can now be terminated on the AFTR address (DS-Lite IPv6 address in
7x50). In this case, the PCP server must be configured in the same routing context as the
DS-Lite (AFTR address) for which the mapping is created/deleted (fwd-inside-router
command under the PCP server configuration). Only one PCP server that is receiving
requests destined to AFTR can be defined per routing context. In other words, only one
PCP server can be configured with the AFTR address that is in the same routing context as
the PCP server itself. [147471]
Starting with Release 11.0.R4, dynamic BGP IPv4 peering for the IPv4 address family is
now supported for LNS (PPP and MLPPP) routed subscriber. [153553]
When an ESM host is created, IGMP general queries are sent towards the host utilizing allzero address (0.0.0.0) as the src-ip. In an IGMP-snooping-enabled network, a port is
considered a multicast router port if it receives an IGMP general query message. In some
cases, only IGMP queries with non-zero src-ip are accepted as an eligible multicast router
port. Release 11.0.R4 allows IGMP general query src-ip under a router instance to be
configured and transmitted as a non-zero address. Individual group interfaces will also
have the ability to override the configured global IGMP query source address. By default,
the src-ip of the IGMP queries will still remain as 0.0.0.0, unless configured. [155291]
The maximum password length has been increased from 10 to 64 characters in a subscriber
management authentication policy: configure subscriber-mgmt authentication-policy
password password. [160628]
L2TP
The LAC initiates the tunnel using registered UDP port 1701 as the destination port in the
Start-Control-Connection-ReQuest (SCCRQ). The LNS replies to the initiators UDP port
and address, setting its source UDP port to a free port number on its own system (which
may or may not be 1701). From that point onwards, the LAC will set the destination UDP
port to match the new LNS source UDP port. This is the new default behavior in Release
11.0.R4 and cannot be controlled via configuration. [134013]
PTP
Release 11.0.R4 supports a larger range of PTP packet rates for sync and delay
request/response packets. Prior to Release 11.0.R4, the SR OS would only grant requests
for sync and delay response PTP packets if the requested packet rate was 32, 64, or 128
packets per second. Starting in Release 11.0.R4, the SR OS will grant these requests for
packets rates as low as one (1) packet per second. Increasing the supported packet rates
allows interoperability with a wider range of PTP boundary and slave clocks. [150660]
Subscriber
Management
116
Enhancements
Release 11.0.R4 introduces the support for accurate Port-Based Timestamping on Ethernet
Link Aggregation Groups. [160028]
Release 11.0.R4 adds the support for IPv6 GRE tunnel transport for soft-GRE tunnels.
WLAN-GW will terminate soft-GRE tunnels with an IPv6 source address. In Release
11.0.R4, the IPv6 soft-GRE tunnel still carries L2 frame with an IPv4 payload. Reassembly
is not supported in this release. [147082]
Release 11.0.R4 provides the support for making the NAS-IP-Address that is sent in
RADIUS messages from MS-ISA configurable. Based on the configuration in isa-radiuspolicy, the NAS-IP-Address can be set as the local IP address of the RADIUS client on the
MS-ISA. By default, the NAS-IP-Address sent in RADIUS messages from the MS-ISA
contains the system IP address. [160029]
Release 11.0.R4 provides the support on WLAN-GW to infer a handover from LTE or
UMTS to WiFi, based on an indication provided by the 3GPP AAA server in its
authentication response. The 3GPP server can provide the IP address of the UE (in AlcWlan-Handover-Ip-Address attribute) and the IP address of the PGW/GGSN (in 3GPPGGSN-Address attribute) in access-accept. The presence of the Alc-Wlan-Handover-IpAddress attribute serves as an indication to the WLAN-GW to set handover indication in
the GTPv2 session creation request to the PGW/GGSN. [160902]
Release 11.0.R4 adds the support for handling RADIUS-initiated disconnect for UEs that
are pending the completion of authentication on the MS-ISA. As part of processing the
RADIUS disconnect message, if a matching UE is found on the MS-ISA in an
unauthenticated state, it is deleted, and an ACK is sent back to the RADIUS server. If a UE
is found in an authenticated state (i.e,. the ESM host exists or has been triggered for the
UE), then a NACK is generated in response to the disconnect message. If no UE state is
found on the MS-ISA, the Disconnect Message is silently dropped. [161216]
Release 11.0.R4 adds the support for five (5) active WLAN-GW IOMs, with a total of six
(6) WLAN-GW IOMs per chassis for redundancy. Prior to Release 11.0.R4, three (3) active
WLAN-GW IOMs were supported with a total of four (4) WLAN-GW IOMs for
redundancy. [161635]
BGP VPWS
When a local site is operationally down, both the D and CSV bits are now set in the BGPVPWS update. Consequently, if the site is shut down on the designated forwarder of a pair
of dual-homed systems, there will be a designated forwarder failover and the remote PE
will now choose the pseudowire to the new designated forwarder to be used to transmit
traffic.
BGP Multi-homing
When using BGP-Multi-Homing with VPLS or Eth-tunnels, the VPLS preference in the
received BGP-MH updates will now be used to influence the designated forwarder (DF)
election.
Application
Assurance
Release 11.0.R4 allows multiple accounting policies with record type of custom-recordaa-sub to be used simultaneously in a node, such as one policy for business AA records
and another for residential AA records. [148375]
WiFi Offload and

Aggregation
117
Enhancements
AQP action for the enrichment of AA subscriber-ID in HTTP requests (GET/POST) for all
HTTP traffic sent to specific servers or domains, and includes optional 128-bit MD5 hash
of the enriched parameter. [156672]
The AA-subscriber accounting file has been enhanced with an option to include export of
the subscriber's app-profile, which allows app-profile-based reporting based on the record
content. App-profile is provided as a configuration option under config>log>accountingpolicy>custom-record>aa-specific>aa-sub-attributes. [159700]
OAM
118
Protocol
Status
Comments
ESPN
new
Provides detection of ESPN audio and video

streaming over RTMP, RTMPT and RTP
Skype Audio-Video
new
Provides separate detection of Skype Audio-Video

traffic from the detection of other types of Skype
traffic
Google Talk
updated
Provides improved detection of Google Talk file

transfers over UDP
IPsec NAT Traversal
updated
Provides improved detection of IPsec NAT Traversal
Microsoft SQL
updated
Provides improved detection of Microsoft SQL

over SMB
Nimbuzz
updated
Provides improved detection of Nimbuzz over TLS
OnLive
updated
Provides improved detection of OnLive gaming and

desktop streaming traffic over RTP
QVOD
updated
Provides improved detection of QVOD media

streams over TCP and UDP
SIP
updated
Provides improved detection of FaceTime over SIP

over TLS
Skype
updated
Provides improved detection of Skype over UDP
Viber
updated
Provides improved detection of Viber over UDP
LLDP packets with the destination MAC nearest-bridge can now be tunneled and treated
as service data using the tunnel-nearest-bridge option. The admin status of the nearest
bridge must be disabled. This is a port-level command and not service-specific. This
enhancement requires IOM3/IMM or higher. [145134]
In Release 11.0.R4, lsp-trace now provides the option to send the echo request packet
without including the Downstream Mapping TLV (DSMAP or DDMAP). This option can
be used to trace the path of a RSVP P2P LSP, LDP FEC, or BGP labeled route without
validation of the incoming interface and incoming label stack. [155487]
Enhancements
Release 11.0.R3
DHCP
A DHCPv4 offer containing a your (client) IP address not matching the locally
configured subnets on the DHCPv4 relay interface is no longer dropped. This change
applies only to regular IES and VPRN interfaces with lease-populate disabled (no leasepopulate) in the DHCPv4 relay-interface configuration. [149299]
IPsec
Release 11.0.R3 adds the support for GRE and IP-in-IP tunnel termination on 7750 SR-c12
(requires MS-ISA). [154999]
Ingress Multicast
Path Management
The maximum plane capacity available in the 7950 XRS-20 platform when using SFMX20-B is 8250 Mbps.
BGP
In order to advertise a MED based on IGP cost in a BGP route sent by an IP-VPN PE to a
CE, a BGP import policy must be used to set the MED metric in the received IP-VPN route
before the import into the VPRN. Prior to Release 11.0.R3, changes in the core IGP cost to
reach the BGP next-hop did not automatically update the MED metric value. Starting with
Release 11.0.R3, IGP cost changes automatically update the MED attribute sent to CE
peers. [152237]
PIM
Starting in Release 11.0.R3, a new option for choosing the preferred Upstream Multicast
Hop (UMH) has been added: unicast-rt-pref. When selected, the best unicast route will
decide which UMH is chosen. Note that all PE routers shall prefer the same route to the
UMH for the UMH selection criteria (for example, BGP path selection criteria must not
influence one PE to choose a different UMH from another PE). [153590]
LAG
Enhanced multicast LAG hashing allows finer granularity of multicast hashing over LAG
interfaces that use per-flow hashing. When enabled, packet content is used to spray
multicast user traffic over available LAG links. OAM traffic generated by CPM continues
to use MID-based hashing. [147429]
PTP
When PTP is configured for boundary clock operation, in order for PTP to be
administratively enabled, at least one timing reference input must be administratively
enabled. Prior to Release 11.0.R3, the PTP timing reference input was automatically
enabled upon enabling PTP, and was not allowed to be disabled while PTP was
administratively enabled. [154675]
PBB
Single TAGs are enabled on B-VPLS SAP on QinQ ports augmenting the current two tag
capability. The SAP definition of 1/1/1:x.0 or 1/1/1:x.* (x.0 and x.* are mutually exclusive
on a port), where x is a VLAN tag value from one (1) to 4094, allows sending and receiving
a single-tagged frame on a port that has QinQ encapsulation. When a B-VPLS is
configured with x.0 or x.* encapsulation, a single-tagged frame with VLAN x may be used
for ingress and egress frames in addition to multiple tags. Ingress SAPs with x.0 (or x.*)
encapsulation accept any frames with outer Tag x (single or two tags) if there is no other
119
Enhancements
SAP with a more specific definition. (e.g., SAP 1/1/1:x.y). The new-qinq-untagged = true
flag can be used to change the x.0 behavior on a node-wide basis to only accept frames with
a single outer Tag x or an outer Tag x and inner tag of 0 only. The syntax of x.* will accept
frames with a single Tag x (if no other more explicit match is configured) or any frame with
an outer tag of x and any inner tag (0 to 4094). [149298]
PPPoE
In Release 11.0.R3, the format for access loop information in the Local User Database
(LUDB) for PPPoE hosts has been enhanced with SAP-id as circuit-id and MAC as
remote-id.
WiFi offload and

aggregation
Release 11.0.R3 adds the support for signaling QoS for primary packet data protocol (PDP)
context on Gn interfaces, and default bearer on S2a interfaces from the WLAN-GW to the
GGSN and PGW. Prior to Release 11.0.R3, fixed default values were used for fields in QoS
profile information elements (IEs) signaled in GTPv1 and GTPv2. Starting with Release
11.0.R3, the content of GTP QoS profile IEs (as defined in 29.274 v9.3.0 for S2a interface
and TS 29.060 v9.5.2 for Gn interface) can be supplied by 3GPP AAA server or proxy in
the 3GPP-GPRS-Negotiated-QOS-Profile attribute, or can be populated from locallyconfigured values on WLAN-GW. [141452]
Release 11.0.R3 adds the support for signaling charging-characteristic information on Gn

and S2a interfaces from the WLAN-GW to the GGSN and PGW. Prior to Release 11.0.R3,
the fixed default value of zero (0) was signaled in charging-characteristic IE in GTPv1 and
GTPv2. Starting with Release 11.0.R3, the charging-characteristic IE content (as defined in
3GPP TS 29.060 version 10.1.0) can be supplied by 3GPP AAA server or proxy in the
3GPP-Charging-Characteristics attribute, or can be populated from locally-configured
values on WLAN-GW. [141457]
Application
Assurance
120
Protocol
Status
Comments
Ares
updated
Provides improved detection of Ares chat room

traffic over TCP.
Hulu
updated
Provides improved detection of Hulu traffic over

TLS.
Skype
updated
Provides improved detection of Skype voice traffic

over UDP.
World of Warcraft
updated
Provides improved detection of World of Warcraft

in-game traffic over TCP.
Enhancements
Release 11.0.R2
HW/Platform
XPL errors will now be reported on ASAP MDAs. [143526]
Application
Assurance
Protocol
Status
Comments
PPStream
updated
Provides improved detection of PPStream over

UDP for new versions of the application.
RDP
updated
Provides improved detection of Win8 Remote

Desktop client traffic over UDP.
Release 11.0.R1
HW/Platform
A new counter, Phys State Chg Cnt, has been introduced in the output of show port
x/y/z for Ethernet ports.
The Phys State Chg Cnt increments when a fully qualified (de-bounced) transition occurs
at the physical layer of an Ethernet port which includes the following transitions of the Port
State as shown in the show port summary:
-
from Down to either Link Up or Up
from either Link Up or Up to Down
The counter does not increment for changes purely in the link protocol states. This means
that if the physical link is up, any transitions in Port State due to link protocols (i.e, 802.3ah
EFM OAM, LACP, 802.1ag) do not cause the counter to increment. The following Port
State transitions are examples of transitions that are not counted:
-
Link Up to Up
Up to Link Up
The Phys State Chg Cnt is available in the TIMETRA-PORT-MIB as object tmnxPortPhysStateChangeCount. [84636]
When a 7750 SR node receives multiple Traffic Selectors (TS) during an IKEv2
negotiation for a dynamic LAN-to-LAN tunnel, if the first Traffic Selector-initiator (TSi)
value is a host address, then the 7750 SR will select from the proceeding TSi values the one
with the longest prefix containing the host address and install it as the reverse route. If the
first TSi is not a host address, then that will be used as the reverse route. [125225]
Starting in Release 10.0.R4, the sapBaseStats MIB has been updated to include two new
entries that contain the packet and octet counts of the amount of protocol traffic received on
a SAP and delivered to the control plane for processing. [126725]
121
Enhancements
122
The fail-on-error mechanism has been extended to include ingress FCS errors detected by
the Pchip for Ethernet line cards. Chassis event ID# 2059 (tmnxEqCardPChipError) has
been added to the list of errors that trigger a card to move to a Failed Operational State if
the fail-on-error mechanism is enabled for that card. Enabling fail-on-error is only
recommended when the network is designed to be able to route traffic around a failed card
(redundant cards, nodes or other paths exist). In the case of fail-on-error being triggered for
a card in the field, further investigation will be required to determine the actual failed
component. [130336]
The event log text, CLI output and MIB description for the tmnxEqCardPChipError event
have been clarified to indicate that this error is reported when a forwarding complex detects
persistent FCS errors in the ingress or egress datapath. [130339]
Prior to Release 10.0.R4, a manual Soft Reset of an IOM would only be allowed if both
MDAs on the IOM supported Soft Reset. Starting in Release 10.0.R4, an IOM will be
allowed to Soft Reset when one or more MDAs cannot be Soft Reset. In this case, the IOM
and the supported MDA(s) will Soft Reset while the other MDA(s) will experience a hard
reset. This capability applies to manual Soft Reset (i.e., clear card <x> soft). In the case of
a manual Soft Reset, an optional keyword (hard-reset-unsupported-mdas) must be
specified in order to force the IOM to Soft Reset when one or more of the MDAs does not
support Soft Reset.
A new accounting record, Ethernet port statistics, has been added and when enabled,
collects the ethernet port statistics (total packet count, crc errors, symbol errors, etc.) in an
XML file. The XML file can be used for further post processing to calculate the ethernet
port vitals (bit error rate, packet error rate, etc.). Starting in Release 10.0.R5, a new
accounting record policy has also been added to report port CRC statistics and error rates.
The new accounting record must be enabled on the desired port and will report the CRC
error count, total non-errored and forwarded frames, and resulting error rate. [131679]
IOM/IMM/XCM firmware will be automatically updated if an older version is detected

upon insertion or hard reset of an IOM/IMM/XCM. [140227]
The c8-atmds1 CMA (part number 3HE02186AA), 12-port Channelized DS3/E3 (DS0)
MDA (part number 3HE00105AA), 1-port Channelized OC-12/STM-4 (DS0) MDA SFP
(part number 3HE00193AA), 4-port Channelized OC-3/STM-1 (DS0) MDA SFP (part
number 3HE00194AA), and 4-port Channelized DS3/E3 (DS0) MDA (part number
3HE00470AA) are no longer supported starting with Release 11.0.R1. [141340]
New firmware has been introduced for m1-10gb-xp-xfp, m2-10gb-xp-xfp, m4-10gb-xpxfp, imm4-10gb-xfp and imm8-10gb-xfp for the PTP port-based timestamping feature.
This firmware also addresses a rare Ethernet management port loss of connectivity issue
for 7750 SR-c4/c12 chassis provisioned with aforementioned MDA types. [141699]
Starting in Release 10.0.R8, an additional level has been added to the 7950 XRS Intelligent
Power Management scheme. With this enhancement, up to seven (7) provisioned XCMs
are supported when a minimum of eight (8) operational Advanced Power EQualization and
control modules (APEQs) are present. The following table provides the power
Enhancements
management levels supported in this release. It does not account for APEQ redundancy; for
+1 redundancy on APEQs, add one to the Operating APEQs count below. [150421]
CLI
System
IPsec
Minimum
number of
Operating
APEQs
Maximum
number of
provisioned
XCMs
11
10
Soft Reset support has been added to the following cards: 2-port 100G, 6-port 40GE and
20-port 10GE MultiCore-CPU FP3-based Ethernet IMMs
IOM/IMM/XCM firmware will be automatically updated if an older version is detected

upon insertion or hard reset of an IOM/IMM/XCM.
A new | count (pipe) option has been added to count the number of lines in the output of
a CLI command. This new command is particularly useful when used in conjunction with
the pipe/match command in order to count the number of output lines that match a
specified pattern. [113305]
The show router isis spf [lfa] [detail] has been deprecated in Release 11.0.R1 and
replaced with the new show router isis topology [ipv4-unicast|ipv6-unicast|mt mt-idnumber][detail] command. [149321]
When a user has too many failed login attempts, they are locked out for a configurable
period of time before they can try again. A new CLI command (and MIB object) allows an
operator to clear the lock-out state for a user: admin user user-name clear-lockout. A new
show routine is also provided to show the current list of users who are locked out: show
system security user lockout. [99271]
A description can now be added to the configuration of a static route. [104825]
Release 10.0.R4 and higher support the removal of an unnecessary looping check that was
previously done by the MS-ISA when it was doing GRE tunnel de-encapsulation. That
loop check prevented the return of CPE-originated GRE keepalive messages. [127026]
The switchover performance for IPsec tunnel groups with a primary and a backup MS-ISA
has been significantly enhanced, resulting in faster traffic recovery times during the
transition from the primary ISA to the backup ISA. [132601]
SR OS supported multi-chassis IPsec redundancy for static LAN-to-LAN tunnels in

Release 10.0.R5, which was only qualified with a specific deployment scenario. Release
10.0.R7 and higher qualify this feature with the following additional scenarios:
-
Static-tunnel-redundant next-hop over spoke-SDP-terminated IP interfaces.
Layer-3 route network on public side with MC-IPsec-aware route policy support.
MC-IPsec-aware route policy to export static routes to MP-BGP or IGP on the private
side.
123
Enhancements
Filter Policies
IP Multicast
LAG
DHCP
124
Release 10.0.R8 and higher add Multi-Chassis IPsec redundancy (MC-IPsec) support for
IKEv2 dynamic LAN-to-LAN tunnels. MC-IPsec was introduced in Release 10.0.R5 for
IKEv2 static LAN-to-LAN tunnels and provides a 1:1 inter-chassis stateful failover
mechanism for IPsec tunnels.
Release 10.0.R8 and higher add a new mc-ipsec-non-forwarding event to the VRRP policy
priority-event context. The system will apply the configured priority when the specified
tunnel-group enters one of these MIMP states: discovery, notEligible, or standby. Only
explicit priority changes are supported for this event and is part of the mandatory command
syntax. [144631]
A new optional to parameter has been added to the tools perform redundancy multichassis mc-ipsec force-switchover command: tools perform redundancy multi-chassis
mc-ipsec force-switchover tunnel-group local-group-id [to {master|standby}] [now]. If
the force-switchover command is executed with the to parameter and the current MCIPsec mastership of the local tunnel-group is the same as the state specified by the to
parameter, then no switchover will take place. [149348]
Release 10.0.R7 and higher add fragmentation support to IPv6 ACL filter policies for FP2and FP3-based line cards. The existing behavior prior to Release 10.0.R7 is preserved with
no fragment configuration while fragment true and fragment false add new match
criteria on the existence or the absence, respectively, of the IPv6 Fragmentation Extension
header in an IPv6 packet. [137843]
Release 11.0.R1 adds support for matching on presence/absence of hop-by-hop extension

header in the IPv6 packet for CPM IPv6 filter policy on 7750 SR, 7750 SR-c4/c12, 7450
ESS in mixed-mode and 7950 XRS. [151741]
Starting in Release 11.0.R1, SR OS has been enhanced to provide optimized replication of

multicast traffic egressing over RSVP-TE LSP-based IES spoke-SDP through the
configuration of multicast-routing-domains. Up to four (4) domains are supported.
[115666]
Release 11.0.R1 enhances the existing multicast IGMP CAC option with an ability to
restrict the maximum number of (S,G)s that will be accepted on the SAP or interface in
non-ESM environments. Prior to this enhancement, only ESM environments were
supported. [135082]
Release 10.0.R4 and higher introduce enhanced diagnostics for LAG and member links
(including inactive sub-group links). New log events and traps on both LAG and link level
have been added for conditions like LACP timer expiry on a member link, partner's
operational bit changes on a member link, LACP RX FSM state changes, dot1ag state
changed on link/LAG, etc. [106334]
Release 11.0.R1 allows a Link Aggregation Group (LAG) to support full per-LAG-link
scale for 40GE- and 100GE-based LAGs (previously limited to 8). A single LAG can serve
up to 3.2 Tbps. [138494]
A new optional CLI parameter event-when-depleted has been added to command

minimum-free under both the pool and subnet level of the local DHCP server. This
Enhancements
parameter enables the system to generate events when the address is depleted in the pool or
subnet. [115564]
OSPF
BGP
Starting with Release 10.0.R4, failover/redundancy is supported in the DHCPv6 Local

Server used for ESM.
The base router now includes a new no-adjacency-check option to the originate-defaultroute command in the configuration of an OSPF Not-So-Stubby-Area (NSSA). Without
this new option, the current behavior applies, which requires a full adjacency in area 0 in
order to advertise the default-route in a type-3 or type-7 LSA into the NSSA. When this
new option is configured, the default-route advertisement requires only that the router is
ABR. For VPRN, this enhancement adds a new adjacency-check option to the originatedefault-route command in the configuration of an OSPF NSSA. Without this new option,
the current behavior applies, which always advertises the default-route in a type-3 or type7 LSA into the NSSA. When this new option is configured, the default-route advertisement
requires that a full adjacency in Area 0 is established. [141570]
In Release 11.0.R1, an enhancement has been made to the OSPF protocols (OSPVv2 and
OSPFv3) to allow control of delay timers for the redistribution of external routes into
OSPF. The three (3) new timers added under the OSPF timer contexts are: lsa-accumulate,
redistribute-delay and incremental-spf-wait.
In Release 11.0.R1, an idle-timeout option has been added to the existing prefix-limit BGP
configuration command. When a BGP session is torn down due to the prefix-limit trigger,
the idle-timeout now indicates how long the system will wait before attempting to
automatically re-establish the session. In prior releases, the idle-timeout was implicitly
forever. [102933]
Release 10.0.R4 and higher provide a new aggregate route configuration option to install
the route in the forwarding table with a black-hole (discard) next-hop. By default, an
aggregate route, once activated, is installed in the routing table but not in the forwarding
table. Installing an active aggregate route in the forwarding table with a black-hole nexthop can avoid issues with routing loops in some network topologies. [126580]
Release 11.0.R1 adds a new field to the output of BGP show commands that displays the
step in the BGP decision process where a BGP route lost the tie-break with the next better
BGP route for the same prefix. This enhancement facilitates troubleshooting and
debugging BGP path selection issues. [126595]
Release 10.0.R7 and higher add a new as-path-group construct to routing policies. An aspath-group is a group of regular expression entries that, from a route matching perspective,
is equivalent to one long regular expression with a logical or between each entry.
[127680]
Release 10.0.R4 and higher allow the TCP MD5 key information used to securely
communicate with a BGP peer to be retained even after the connection has closed, allowing
connectionless RST packets to be sent with the proper authentication data. [128215]
Release 10.0.R4 and higher introduce a new configuration command to control whether or
not a best BGP route received from a BGP peer is reflected back to that peer along with
other peers when the route is propagated throughout the BGP network. By default no effort
is taken to prevent a best route from being reflected back to the sending peer. [128638,
140336]
125
Enhancements
MPLS/RSVP
Starting in Release 10.0.R4, a new optional keyword, skip-peer-as, has been added to the
remove-private command and changes the behavior of the command so that if the ASN of
the remote peer is a privates ASN, that ASN is not removed from the AS path. This
enhancement allows the remove private command to strip other private ASNs from the ASpath but maintains the private ASN of the peer so that loop detection can still work.
[129909]
Release 11.0.R1 adds the option to prepend only the local-AS and not the global-AS when
advertising routes to an eBGP peer configured for local-AS operation. When this option is
not specified, the default behavior applies: in advertised routes towards the eBGP peer, the
global-AS is prepended first to the AS-path, and then the local-AS. [130263]
Release 11.0.R1 introduces a new configuration option to the base-router BGP instance to
allow a route reflector of IP-VPN routes to be deployed in the datapath (i.e., by setting
next-hop self, advertising a new label value and programming a label swap operation in the
line cards). [135235]
Release 11.0.R1 improves the way SR OS supports matching, adding, deleting or replacing
multiple BGP communities in route policies. It allows multiple community names to be
specified in the match or the action part of a policy entry. As community names must be
enclosed in square brackets when they are included in a match expression, inclusion of
square brackets in community names themselves is no longer supported and execution of
configurations with such names will fail from Release 11.0.R1 onward. [139643]
Release 11.0.R1 doubles the size of the ECMP next-hop table on FP2- or higher-based line
cards and 7750 SR-c4/c12 to improve scalability in BGP label-per-prefix deployments.
[143215]
It is possible to configure the address of a loopback interface other than the router-id as the
destination of an RSVP LSP or a P2MP S2L sub-LSP. In the case of a CSPF LSP, CSPF
searches for the best path that matches the constraints across all areas/levels of the IGP
where this address is reachable. If the address is the router-id of the destination node, then
CSPF selects the best path across all areas/levels of the IGP for that router-id and
regardless of which area/level the router-id is reachable as an interface.
In addition, the user can now configure the address of a loopback interface other than the
router-id as a hop in the LSP path hop definition. If the hop is strict and corresponds to
the router-id of the node, the CSPF path may use any TE-enabled link to the downstream
node based on the lowest cost. If the hop is strict and does not correspond to the router-id
of the node, then CSPF will fail. [113994]
QoS
126
Self-Generated Traffic QoS (sgt-qos) application arp has been enhanced to include
Subscriber Host-Connectivity Verification (SHCV) ARP frames for IPv4 hosts that egress
on a subscriber interface (L3) or subscriber SAP (L2). The default QoS marking value for
SHCV ARP frames has changed to a dot1p value of seven (7). [81448]
Enhancements
The following Self-Generated Traffic QoS (sgt-qos) applications have been enhanced to
include packets egressing on a subscriber interface:
-
dhcp now includes support for DHCPv6 packets
ndis now includes support for Neighbor Discovery packets (NS/NA/RA), including
Neighbor Solicitation (NS) packets for Subscriber Host Connectivity Verification
(SHCV) for IPv6 hosts
icmp now includes support for ICMPv6 packets
The default QoS marking values for these packets has changed to a dscp value of nc1 and
a dot1p value of seven (7). After an upgrade, sgt-qos should be explicitly configured if
downstream equipment is relying on the QoS marking. [92554]
MPLS/RSVP
LDP
Management
Starting in Release 10.0.R4, it is now possible to tune the responsiveness of the virtual
scheduler for a set of queues using the QoS virtual-scheduler-adjustment policy. This is
supported on all FP2- and FP3-based line cards.
Egress forwarding-class override provides additional QoS flexibility by allowing the use of
a different forwarding class at egress than was used at ingress. This is achieved by
overriding the forwarding class, or forwarding sub-class, used by the SAP ingress
processing so that a different forwarding class is used by the egress QoS processing. The
egress could be either access egress (SAP) or network egress. This is supported on FP2and higher-based line cards.
The new tools dump mpls-resources CLI command displays the consumption of standard
MPLS data path resources by the LDP, RSVP, and BGP control-plane protocols. These
resources are the Incoming Label Map (ILM) for the advertized tunnel or service label, the
Next-Hop Label Forwarding Entry (NHLFE), and the Label-to-NHLFE (LTN). [125785]
Starting in Release 10.0.R4, an LSP that uses the TE metric in the CSPF path calculation
can now have its operational metric overridden with the user-configured administrative
LSP metric. The operational metric is used in IGP shortcut and LDP-over-RSVP
applications. [132084]
Release 10.0.R4 and higher provide an option to specify a file location in an accounting
policy used only for MPLS auto-bandwidth. If the to no-file option is specified, LSP
statistics are not stored and are merely passed through to MPLS for auto-bandwidth rate
measurements. [135722]
Release 11.0.R1 aligns the setting of the tunnel metric in the Tunnel Table Manager (TTM)
for an LDP FEC resolved to an RSVP LSP and sets it to the value of the LDP FEC prefix
metric in the Routing Table Manager (RTM). An LDP FEC can resolve to an RSVP LSP if
the user enables the LDP-over-RSVP feature or the IGP shortcut feature. [141774]
Release 11.0.R1 relaxes downstream next-hop check in mLDP FEC resolution. For each
downstream LSR node sending a label mapping, the upstream LSR node will resolve the
mLDP FEC to as many interfaces as the value of the system-configured ECMP option. It
will base this selection on the ascending order of interface index in the routing instance.
[141819]
Starting in Release 10.0.R4, the ifAlias value within the IfXEntry MIB table is set based on
the description string configured under the associated port or logical interface. As a result,
127
Enhancements
ifAlias will be different from the value returned in the ifDescr field as the system's
port/interface name and type are not prepended to the ifAlias value. [116426]
Routing
Starting in Release 10.0.R5, an event is generated and a trap is sent when the status of a
static route (prefix and next-hop) changes from active to inactive or from inactive to active.
[105968]
Starting in Release 10.0.R5, Global-Route-Table (GRT) leaking has been enhanced to

permit leaked base-instance system interfaces to respond to management connections and
SNMP requests coming from a VPRN. This functionality supports operators who wish to
run network management in a VPRN instance and permit that VPRN to reach the system
interface in the base routing instance.
This function is enabled by configuring the optional keyword allow-local-management
under the enable-grt configuration item under the grt-lookup hierarchy in the VPRN
service. Protocol support is limited to SSH/FTP/telnet/SNMP on IPv4 only. Ping and traceroute responses from the base router are supported by default and are not configurable.
[120243]
Ingress Multicast
Path Management
128
Release 11.0.R1 introduces a new strict-no-ecmp uRPF mode in addition to the existing
strict and loose modes. The strict-no-ecmp mode can be configured on any interface that is
known to not be a next-hop of any ECMP route. When a packet is received on an interface
in this mode and the source address (SA) matches an ECMP route, the packet is dropped by
uRPF. [135927]
Release 11.0.R1 introduces the support for base-router interfaces to respond to IPv6 traffic
GRT-leaked from VPRNs for the purposes of system management. This support is limited
to SSH, telnet, FTP, traceroute, ping, and SNMP. When the allow-local-management
keyword is configured, the system will respond to IPv4 and IPv6 traffic leaked from a
VPRN to the GRT. [136403]
Release 10.0.R5 and higher offer improved accuracy of the IPv6 FIB current occupancy
statistic. [141555]
A set of commands introduced in Release 10.0.R4, under configure>mcastmanagement>chassis-level>per-mcast-plane-capacity, allow the maximum multicast
primary and secondary plane capacity to be statically defined or dynamically derived based
on the provisioned line cards and switch fabrics in the chassis. As the individual total plane
capacity can change dynamically, the plane capacities available with or without a full
complement of active switch fabrics are defined as a percentage of total plane capacity. The
total plane capacity is configured to be derived dynamically. When the total plane capacity
is derived dynamically, all SR/ESS systems will use a total of 2000 Mbps with the
exception that when only 100G FP2-, 100G FP3- or 200G FP3-based line cards are used in
an SR/ESS with an SF/CPM4, or when only FP3-based line cards in used in an SR-12e, the
total plane capacity used will be 4000 Mbps. These totals should not be exceeded when
configuring the plane capacities statically. The maximum plane capacity available in the
7950 XRS-20 platform is 5250 Mbps; this is used by the system when the total plane
capacity is derived dynamically.
By default, ingress-policed broadcast, multicast or unknown traffic and point-to-multipoint

LSP traffic is distributed across IMPM paths using hash mechanisms. The distribution has
been optimized when IMPM is enabled on any forwarding complex to allow this traffic on
Enhancements
all forwarding complexes to be redistributed by the system across the IMPM paths in order
to achieve a more even capacity distribution. [145967]
Services General
Prior to Release 10.0.R4, if a SAP or spoke-SDP operational down PW status message was
received, then the status would be mapped to the appropriate OAM message on the SAP
access circuit. Block on operational down introduces the ability for the PE to drop user
packets received on a SAP if one of the operationally down PW status bits is set for the
corresponding spoke-SDP. This prevents user traffic from being forwarded across the
MPLS network, only to be dropped at some downstream defect point.
This behavior is configured in CLI as follows:
config>service>epipe>spoke-sdp
config>service>pw-template
[no]block-on-peer-fault
Default: disabled
When block-on-peer-fault is enabled, it blocks Tx direction of a PW when any of the following PW status codes is received from the far end PE:
0x00000001
Pseudowire Not Forwarding
0x00000002
Local Attachment Circuit (ingress) Receive Fault
0x00000004
Local Attachment Circuit (egress) Transmit Fault
0x00000008
Local PSN-facing PW (ingress) Receive Fault
0x00000010
Local PSN-facing PW (egress) Transmit Fault
It unblocks the Tx direction when the following PW status code is received:

0x00000000
Pseudowire forwarding (clear all failures)
The command is mutually exclusive with no pw-status-signaling and standby-signalingslave. It is not applicable to spoke-SDPs forming part of an MC-LAG or spoke-SDPs in an
endpoint. [129052]
Subscriber
Management
Release 10.0.R5 and higher add two changes to reduce possible timing issues with BGP
MH designated forwarder election: 1) The BGP-MH site is brought down before sending
the BGP-MH NLRI with DF/down bits set to false; 2) A local ACK has been added that
confirms the BGP-MH site is down before declaring as non DF in BGP. [133354]
A new optional description flag has been added to the show service sap-using CLI
command to display a SAP summary table including the port-id, service-id, administrative
and operational states, and the SAP description.
Starting in Release 10.0.R5, it is now possible to configure the system-wide UDP port
number that RADIUS is listening to for CoA and disconnect messages: configure aaa
radius-coa-port <3799 | 1700 | 1812 | 1647>. Port 3799 is the default port. [83491]
129
Enhancements
Starting in Release 10.0.R4, PPPoE session can be terminated via CoA using the session
timeout RADIUS attributes with absolute or relative values. The following two attributes
are now supported in RADIUS CoA and Access-Accept messages:
-
[27] Session-Timeout
Standard RADIUS attribute that resets the current PPPoE session timeout to an
absolute value. If the current session time is greater than the newly received SessionTimeout, a CoA NAK is sent with error cause Invalid Attribute Value.
[26-6527-160] Alc-Relative-Session-Timeout
Alcatel-Lucent-specific RADIUS attribute that resets the current PPPoE session
timeout to a relative value (current session time + newly received Alc-RelativeSession-Timeout).
Once the PPPoE session timeout expires, the PPPoE session will now be terminated.
RADIUS-attribute manipulation via Python scripting can now be used in case that the standard [27] Session-Timeout attribute in CoA needs to be regarded with relative value.
[107222]
Starting in Release 10.0.R4, PPPoE user authentication options in a ppp-policy is enhanced

with a new type pref-pap:
config>subscr-mgmt>ppp-policy# ppp-authentication {pap | chap | pref-chap | pref-pap}
pap: always use PAP to authenticate the sessions
chap: always use CHAP to authenticate the sessions
pref-chap (default): attempt to use CHAP and if it fails, use PAP
pref-pap: attempt to use PAP and if it fails, use CHAP [112867]
The following parameters configured at the top of the L2TP hierarchy (configure router
l2tp or configure service vprn id l2tp) will be used as default parameters in case they are
absent from the RADIUS supplied configuration or are missing under a more specific
(group or tunnel level) CLI hierarchy:
-
local-address
local-name
password
session-assign-method
idle-timeout
hello-interval
destruct-timeout
max-retries-estab
max-retries-not-estab
avp-hiding
challenge
session-limit (limits the number of sessions per router or service)
tunnel-session-limit (limits the number of sessions per tunnel)
group-session-limit (limits the number of sessions per group level)
With this, all LAC parameters that can be specified on group level can then be specified on
a router level as well.
130
Enhancements
If the L2TP parameters are supplied via RADIUS, then they will have preference over any
locally supplied parameters. L2TP parameters missing in RADIUS will be, by default,
taken from the router-level configured values.
In case there is no RADIUS server present in the network and consequently L2TP parameters are supplied via local configuration, the order of evaluation will be the following:
-
tunnel-level parameters from local configuration
group-level parameters from local configuration
router-level parameters from local configuration
Note that for the LAC case, if the RADIUS returns only an L2TP group name, then this
group name must reference a locally configured group name that contains all parameters
necessary to establish a tunnel or a session with the tunnel. On the other hand, if the locally
configured (existing) L2TP group name is returned via RADIUS along with some other
L2TP parameters, the session establishment will fail as the group name will be declared
invalid. [113363]
ESM Multi-Chassis Sync (MCS) is now supported on hybrid ports and LAGs. See Table
on page 183 for unsupported MCS client applications. [123469]
Starting in Release 10.0.R4, wholesale providers can now deliver Internet access to directly
connected PPP users through third-party ISPs. This involves the users connecting to an
L2TP Access Concentrator (LAC) with their traffic being tunneled to and from an L2TP
Network Server (LNS) in their ISP. A new command, use-ingress-l2tp-dscp, has been
added to the sla-profile egress CLI node to support per-ISP (and per-subscriber host) QoS
control for downstream traffic on the LAC towards the users based on the DSCP marking
in the L2TP header. This enhancement is only supported for subscribers instantiated on
FP2- or higher-based line cards or on 7750 SR-c4/c12. [126185]
Starting in Release 10.0.R4, when in per-session accounting mode of operation, when an

IPv4/v6 address is allocated or released from a dual-stack host, a triggered Interim-Update
message will be immediately sent. This triggered Interim-Update message will reflect the
change in the IP address. The triggered Interim-Update has no effect on the interval at
which the regular Interim-Updates are scheduled. This feature is supported for PPPoE
hosts only. [127772]
Starting in Release 10.0.R4, every time an Interim-Update message is triggered outside of

its scheduled interval, an optional new VSA can be included to convey additional
information about the trigger that caused the Interim-Update message to be transmitted.
For example, a triggered Interim-Update may be a consequence of an IP address
allocation/de-allocation for subscriber-host in per-session accounting mode. In this case,
the triggered reason VSA will now update the status of the IP address (allocated or deallocated). Triggered Interim-Updates are also a consequence of updating the sla-profile
instance for the host in per-host or per-session modes of accounting. In such case,
triggered reason VSA will now convey the information whether the Interim-Update is
the consequence of sla-profile instance allocation or de-allocation. [127873]
VID type MAC-filters can now be configured on a capture-SAP. This provides additional
control on the VLANs that are allowed to initiate a subscriber setup. [128927]
It is now possible to configure a DHCPv6 Vendor-specific Information Option (17) as a

custom-option in a DHCPv6 local-dhcp-server. Prior to Release 10.0.R3, this was
blocked in CLI. Only the hexadecimal string format (hex) is valid for the Vendor-specific
Information Option (17) custom-option even though the format is not enforced in CLI. All
131
Enhancements
other formats do not support the code-length-value encoding of the option data field.
[131089]
It is now possible to filter on group-interface when debugging IGMP packets for multichassis ESM (MC-ESM). [132319]
Prior to Release 11.0.R1, the standard session-timeout RADIUS attribute in RFC 2865
was interpreted as DHCP lease time. This enhancement decouples session timeout for IPoE
sessions from DHCP lease time. A timer is maintained for the session timeout value
provided in session-timeout attribute from RADIUS. The expiry of the timer results in
deletion of the session and the corresponding lease, release of all resources associated with
the session, and generation of accounting-stop message. The DHCP lease is managed
independent of the session timeout.
A new VSA (Alc-Lease-Time) is now supported for RADIUS to provide DHCP lease time.
For backwards compatibility, in DHCP proxy mode, if Alc-Lease-Time VSA is not present
in access-accept but the session-timeout VSA is present, then Alc-Lease-Time is interpreted as DHCP lease time as before. However, if both Alc-Lease-Time and session-timeout attributes are present, then the session-timeout and DHCP lease times are enforced
independently. The session-timeout attribute by default is interpreted relative to the start of
the session. However, if Alc-Relative-Session-Timeout VSA is provided, then the sessiontimeout is relative to current time at the reception of the VSA. [132694]
132
Starting in Release 10.0.R4, the following RADIUS attributes can now be changed in a
CoA message: [1] User-Name, [25] Class, [30] Called-Station-Id and [26-6527-148] AlcRSSI. [133935]
DHCPv4 over PPPoE is now supported. Unicast DHCPv4 packets for PPPoE subscribers
are transparently forwarded. Refer to Known Limitations on page 183 for restrictions
that apply. [137283, 138115, 138890]
For PPPoE CHAP RADIUS Authentication, when the CHAP challenge is exactly 16 bytes
long, it is now also copied in the request-authenticator field of the RADIUS AccessRequest message as allowed in RFC 2865 section 2.2. This is to ensure interoperability
with certain field-deployed RADIUS proxy/server configurations. [140961]
For IPoE subscribers, a new dual-stack-remote-id option has been introduced to autogenerate a subscriber name (sub-id). The dual-stack-remote-id option will ignore the
enterprise-number part of the DHCPv6 relay agent remote-ID so dual-stack IPoE hosts
result in the same auto-generated subscriber name (sub-id). [142706]
The behavior of the unique-sid-per-sap flag in a ppp-policy was changed when used in
combination with managed SAPs. Starting from Release 9.0.R7, a maximum of 1023
sessions with a unique session id (1 to 1023) was supported per capture SAP. For backward
compatibility with pre-9.0.R7 releases that do not have this limitation, Release 10.0.R5 and
higher introduce a CLI option per-msap that can be configured to revert to the uniquesid-per-sap behavior. The per-msap configuration is not default in order to be backwardcompatible with post-9.0.R7 software. [144935]
Upon receiving an LCP-Terminate-Request from a PPPoX client, the RADIUS Accounting

process will immediately trigger a stop timestamp and place the host in a non-forward
state. The clients total session time will be from the start of the session to the time when
the LCP-Terminate-Request was received. Previously, the stop timestamp was triggered
upon receiving a PADT. This new RADIUS Accounting behavior applies to both sessionaccounting and host-accounting. Queue-instance-accounting does not follow this new
RADIUS Accounting behavior. [145215]
Enhancements
An alarm has been added to MAC-move for a SAP/SDP that is non-blockable. The alarm
frequency is the same as MAC-move for blocked port, but will slow to a longer interval if
the condition persists. There is no change in the forwarding behavior. [136259]
A Routed-VPLS service now allows IPv4 multicast routing when the source is located on
the IP interface side of the service with receivers on the VPLS side of the service. PIM and
IGMP are supported on the IP interface. When IGMP is configured on the IP interface, it is
mandatory to enable IGMP-snooping in the VPLS when dynamic IGMP joins are used.
However, multicast traffic can be sent into the VPLS without IGMP snooping enabled by
using static joins on the IP interface. 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.
VPRN/2547
Release 10.0.R4 and higher support blackhole routes leaking into the GRT.
Accounting
Starting in Release 11.0.R1, accounting policy has been enhanced to include a new
accounting record type: complete-network-ingress-egress. The new record combines, in a
single record, information available in network-ingress-packets, network-egress-packets,
network-ingress-octets, and network-egress-octets records. [128937]
Starting in Release 11.0.R1, operators can now include the SAP description as part of
accounting records generated and the new record order value tags. To use the new
functionality, the operator needs to select a new record type of extended-service-ingressegress. The XML tags for the new fields are des for SAP description, first, and next
for new order value (in addition to the existing tag value of final). [142879]
With Release 11.0.R1, all accounting record types now have additional information under
router-info when enabled.
In Release 11.0.R1, traffic traversing NAT can be optionally filtered in the IOM. For
example, once the DS-Lite traffic in the upstream direction is de-capsulated and NATd,
the resulting IPv4 traffic can be optionally subjected to filtering in order to protect the
control-plane. [122723]
VPLS
NAT
133
Enhancements
PPPoE
134
Starting in Release 10.0.R4, the following resource consumption in NAT can now be
monitored via CLI:
-
Flows
Policies
Port ranges
Ports
IP addresses
Large-scale hosts
Subscriber-cache entries
L2-aware subscribers
L2-aware hosts
Delayed ICMPs
ALG session
Upstream fragment lists
Downstream fragment lists
Upstream fragment holes
Downstream fragment holes
Upstream fragment buffers
Downstream fragment buffers. [122724]
The magic-number checks on LCP Echo-Request and Echo-Reply messages can be

ignored for PPPoE or LNS sessions. [134391]
Subscriber retention functionality has been enhanced so that logs are created only when the
port-block is returned to the pool after the retention timer has expired. In addition, a new
internal timer of one (1) second in an outside pool is introduced that prevents reassignment
of a port-block to a new subscriber while the port-block is associated with the subscriber in
a retained state. [134648]
Statistics counters for NAT are expanded from 32-bit to a 64-bit length. 32-bit counters are
still maintained in order to preserve backward-compatibility with SNMPv1. The statistics
counters are part of the tmnxNatIsaMemberStatsTable also visible via the show isa natgroup grp-id member member-id statistics command. [135167]
To avoid transient issues with Static Port Forward (SPF) in a multi-chassis environment,
the SPF creation will be blocked on the standby node when an outside IP address is not
specified. A boolean value in variable tmnxNatFwdActionSucessfull indicating a failure
will be returned to the requester. To determine whether the failure of SPF creation was
actually due to the fact that the NAT function was down, the SNMP management system
needs to read the tmnxNatPlLsnTable and inspect the object tmnxNatPlLsnRedActive. If
an outside IP address is specified in the SPF request, the mapping will still be created on
the standby node since this is how the mappings are synchronized in a multi-chassis
environment. [138556]
To support IPv4 address allocation using the internal DHCPv4 client for multiple PPPoE
sessions on a single SAP and having the same MAC-address and circuit-ID, a new optional
CLI flag has been added to the max-session-per-mac command in a ppp-policy: maxsessions-per-mac sessions [allow-same-circuit-id-for-dhcp]. [139346]
Enhancements
Chap-challenge length is now configurable in LNS. [141713]
The following additional PPPoE checks have been added:

-
only accept PADI with destination address = broadcast
only accept PADR with destination address = own MAC. [142862]
In response to an L2TP tunnel establishment reject message (StopCCN) or a session

establishment reject message (CDN), another attempt will be made to bring up another
L2TP tunnel within the same preference level or the next preference level. The preferencelevel method is configurable using the new next-attempt command. [145092]
Routable Lawful-Intercept (LI) encapsulation support was added in Release 10.0.R1. In

Release 10.0.R4, support for MS-ISA NAT-based Lawful Intercept (NAT li-source entries)
with Routable-LI encapsulation has been added.
LI at the LNS for MLPPPoX (oE/oA/oEoA) subscribers is now supported with mirror-dest
type ip-only. No other mirror-dest types are supported with this enhancement.
An IPv6-filter entry can now be used as an li-source or debug mirror-source. This includes
support for ether or ip-only mirror-dest types.
Prior to Release 11.0.R1, only simple DNS resolution for default WLAN APN to one or
more A records was supported. This enhancement provides support for S-NAPTR
procedures for default WLAN APN resolution and PGW selection as defined in 3GPP TS
29.303 version 8.0.0 Release 8. The S-NAPTR procedures provide SRV records and
ultimately A/AAAA records. The construction of APN-FQDN to be resolved is as per
3GPP TS 23.003 version 10.2.0 Release 10. [141453]
WiFi Offload has been enhanced to support the Upstream L2oGRE reassembly.
Basic DNS procedures, A-records and S-NAPTR from DNS server are now supported. IP
MTU enforcement on soft-GRE interface for downstream GTP-encapsulated traffic is also
supported.
Cflowd
An IPv6 address can now be defined for a Cflowd collector. An IPv6 Cflowd collector can
be configured to receive flow information in either Netflow v5, v8, v9, or v10 (IPFIX)
format. [121364]
Application
Assurance
Release 10.0.R2 and higher support 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: HTTP and QQ. For a complete list of the Release 10.0 AA identification
release are: DNS, MSN Messenger, Opera Mini, ooVoo, RTP, Skype, TiVo, WebEX and
XBox Live. For a complete list of the Release 10.0 AA identification capabilities
(protocols and applications), contact your regional support organization.
release are: BGP, Facebook, GTP, HTTP, MS Communicator, MS Messenger, NetBIOS,
STUN, Sybase, Weixin and WhatsApp. For a complete list of the Release 10.0 AA
Mirroring/Lawful
Intercept (LI)
WiFi Aggregation
and Offload
135
Enhancements
identification capabilities (protocols and applications), contact your regional support

organization.
release are: Betamax VoIP, CNN Live, DNS, Gnutella, IPSec NAT Traversal, MS
Communicator, Octoshape, Opera Mini, PPTP, QQ and Viber. For a complete list of the
Release 10.0 AA identification capabilities (protocols and applications), contact your
regional support organization.
release are: DNS, MS Exchange, ooVoo, RTMP, RTP, Siebel, TLS, uTP. For a complete list
of the Release 10.0 AA identification capabilities (protocols and applications), contact your
regional support organization.
Release 10.0.R8 supported a new version of the isa-aa.tim file that enables new and
are: Funshion, Justin.tv, QVOD, RDT, RTP_RTSP, Slingbox, Spotify, TLS, Tor, Ustream
and uTP. For a complete list of the Release 10.0 AA identification capabilities (protocols
and applications), contact your regional support organization.
136
Protocol
Status
Comments
Funshion
new
Provides detection of Funshion streaming over

UDP, TCP and HTTP.
Game Center
new
Provides detection of the Apple Game Center UDP

peer-to-peer multiplayer protocol.
Justin.tv
new
Provides detection of Justin.tv audio/video streaming over RTMP/RTMPT and website access.
OnLive
new
Provides detection of OnLive Gaming and Desktop

Streaming Traffic over RTP.
Spotify
new
Provides detection of Spotify audio streaming, control and track selection over UDP and TCP.
Ustream
new
Provides detection of Ustream audio/video streaming over RTMP/RTMPT.
BitTorrent
updated
Provides improved detection of BitTorrent traffic

for newer uTorrent clients.
BitTorrent
updated
Provides detection of the BitTorrent UDP Tracker

protocol.
HTTP Web Feed
updated
Provides detection of UTF-16 HTTP RSS and

Atom web feeds.
Manolito
updated
Provides improved detection of file transfers over

TCP and UDP control traffic.
Enhancements

PPLive
updated
Provides improved detection of PPLive rtp traffic.
QVOD
updated
Provides improved detection of Qvod over

HTTP/UDP/TCP.
RDT
updated
Resolves a false-positive detection scenario where

specific GTP traffic was detected as Real Player rdt.
RTSP
updated
RTP media flows signalled by a RTSP control session will now be detected as rtp_rtsp and associated
with RTSP.
Slingbox
updated
Provides improved detection of HTTP sessions on

iOS devices.
Teredo
updated
Provides detection of variable length Teredo headers.
TLS
updated
Provides improved detection of TLS when TCP

segments are out of order.
TLS
updated
Provided detection of non-basic ASCII characters

in TLS strings.
TLS
updated
Provides improved detection of clients using multiple versions of TLS within a single TLS session.
Tor
updated
Provides detection of Tor when the obfsproxy

plugin is used, which can obfuscate TLS data.
Weixin
updated
Provides detection of Weixin live video chat over

UDP.
In Release 11.0.R1, use of the ip-protocol field in AQP matches allows for a more precise
control of match criteria (e.g., to specify port or IP address matches specifically for either
TCP or UDP). Use of charging-group in AQP matches allows a policy control or
enhancement to be applied to the set of traffic represented by a charging group. [126201]
Release 10.0.R4 and higher extend the Application-Assurance filtering capabilities by

allowing to match any single character, any single decimal, the asterisk character (*) and
optionally to force case sensitivity. It is available on any type of expression-string-based
app-filters. [127077]
Release 11.0.R1 allows the operator to perform AA classification by matching the URL
used in the RTSP protocol. The operator may choose to differentiate its AA reporting, AA
control and/or charging rules by RTSP URL. RTP and RDP data flows associated with the
RTSP control session are classified using this new expression filter. [136632, 137851]
In Release 11.0.R1, the AA HTTP-redirect AQP action has been enhanced to allow HTTPredirect either on blocked traffic (dropped flows) or optionally, admitted flows. This allows
HTTP-redirect for selective traffic steering of HTTP traffic while not affecting other traffic.
[138328]
In Release 10.0 and higher, HTTP redirect using an HTTP 302 response capability provides
a new template ID in the redirect template policy. [139226]
Release 11.0.R1 allows the operator to report protocol, application, and app-group volume
usage per forwarding class (FC) by adding a bitmap information representing the observed
FC in the XML accounting files. [139636]
137
Enhancements
OAM
138
The following counters have been added to the AA performance planning record in Release
11.0.R1:
-
AA-Subs Created
AA-Subs Deleted
AA-Subs Modified
Seen-IP Requests Sent
Seen-IP Requests Dropped
transit-prefix v4 address count
transit-prefix v6 address count
transit-prefix v6 remote address count [146490, 146551]
Release 10.0.R7 introduced the new HTTP-redirect template to provide HTTP 302 redirect
containing only the URL specified in the redirect policy with no other parameters.
[146650]
The p2mp-lsp-ping and p2mp-lsp-trace implementation has been updated to use the new
Downstream Detailed Downstream Mapping (DDMAP) TLV as per RFC 6425. This TLV
is used when performing a p2mp-lsp-trace of a single leaf of a RSVP P2MP LSP or when
causing a p2mp-lsp-ping packet to expire in a node in the path of a RSVP P2MP LSP, or a
multicast LDP (mLDP) FEC which is not the leaf node itself. The prior implementation
was based on the pre-RFC version of the IETF draft, draft-ietf-mpls-p2mp-lsp-ping-06, and
used the classic Downstream Mapping TLV (DSMAP). [99555]
Up to 10 Maintenance Associations (MAs) can now be configured with more than 64 total
MEPs up to a maximum of 400 MEPs in the MA. This requires SF/CPM3 or higher.
[126090]
Port and LAG Facility MEPs now include support for NULL encap-type for network and
access modes. [128004]
VCCV-Ping and VCCV-Trace have been added to VPLS for psuedowires that interconnect
VSI within a VPLS. This is applicable only to FEC128-PWs. [130107]
An SR OS router will now respond to a received vprn-ping or vprn-trace packet when the
tested prefix is reachable via a VPRN spoke-interface. [131014]
It is possible to ignore the reception of interface-status and port-status TLVs in the ETHCCM PDU on Facility MEPs (Port, LAG, QinQ Tunnel and Router) using the optional
ccm-tlv-ignore command. [131505]
Starting in Release 10.0.R5, port-based Facility MEPs now support MD levels up to level
one (1). [134832]
Release 10.0.R8 and higher support the new padding-size optional parameter to the
VRRP host-unreachable test under priority-event, allowing the padding size for the ICMP
ping test packet to be set to a specified size. [138987]
A new size bytes optional parameter has been added to the static-route command,
allowing the packet size for the ICMP ping test packet to be set to a specific size. If the
cpe-check option is configured for a static route, the administrator can also specify a
size value if desired. This option only applies to IPv4 static routes. [138990]
In Release 11.0.R1, the show system lldp neighbor command output has replaced the
Port ID (which printed the ifIndex value) with a new column Remote Port. The
Remote Port column will include the ifDesc (RFC 2863 IF-MIB) when the port-
Usage Notes
description TLV is received. If there is no port-description TLV received or the value is

null, the ifIndex will be printed. The show port ethernet lldp nearest-bridge remote-info
detail command output has been enhanced to print appropriate characters based on the
received type. [143521]
Usage Notes
The following information supplements or clarifies information in the manuals for Release
11.0.R20 of SR OS.
XCM and SFM
Recovery
Behavior
7750 SR-12e
In a 7950 XRS system, at least one SFM must be fully operational in order for the XCMs,
XMAs and standby CPM to be in service. If there are no operating SFMs in the system,
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.
For optimal performance, it is recommended that up to four (4) FP2-based IOMs/IMMs

supported in the SR-12e are installed in up to four (4) consecutive slots (e.g., slots 1-4 or 2-5,
etc.).
7450 ESS-7/12 and

7750 SR-7/12
Specific engineering rules may apply when mixing FP2- and FP3-based line cards; please
contact your Alcatel-Lucent representative for further details.
Common Software
Image Set for All
Platforms
A common software image set is used across the 7750 SR, 7450 ESS, 7710 SR and 7950 XRS
platforms.
PPPoE CLI
Changes
A new ppp node has been created under:
configure>services>ies>subscriber-interface>group-interface
configure>services>vprn>subscriber-interface>group-interface
The pppoe-policy command has been renamed to ppp-policy under:
configure>subscriber-management
configure>service>ies>subscriber-interface>group-interface>pppoe
configure>service>vprn>subscriber-interface
The pppoe node under configure>subscriber-management>local-user-db has been renamed into

ppp.
The ppp node is maintained in parallel with the existing pppoe node under the same hierarchy.
In Release 9.0.R4 and higher, the commands under the ppp node have relevance for PPPoA
sessions while the commands under the pppoe node have relevance for PPPoE/PPPoEoA
sessions.
139
Usage Notes
Seamless migration from earlier software releases is supported through the upgrade process.
Downgrading from Release 9.0 is not supported. MIB objects for renamed objects have not
changed.
LUDB access for PPP/PPPoE sessions via a capture SAP has been added under:
configure>service vpls id> sap sap-id capture-sap> pppoe-user-db ludb-name
configure>service vpls id> sap sap-id capture-sap> ppp-user-db ludb-name
When authentication-policy (RADIUS authentication) is specified under the capture SAP,

RADIUS authentication will take precedence over LUDB. LUDB authentication via capture
SAP is enabled only for PPP/PPPoE clients and not for IPoE clients.
IPsec CLI Changes
The following IPsec CLI changes were introduced in Release 8.0.R4 to unify CLI names of
IPsec tunnels and support for future tunneling options.
TABLE 30. IPsec CLI Changes
Release 8.0.R3 and lower
Release 8.0.R4 and higher
config>card>mda>mda-type isa-ipsec
config>card>mda>mda-type isa-tunnel
config>isa>ipsec-group
config>isa>tunnel-group
config>service>vprn(or ies)>if>sap
ipsec-x.public:y
config>service> vprn(or ies)>if>sap tunnel-x.public:y
config>service>vprn>ipsec-interface zzz
config>service>vprn>interface zzz tunnel
config>service>vprn>ipsec-if>sap ipsecx.private:y
config>service>vprn>if>sap tunnel-x.private:y
config>service>vprn>ipsec-if>sap>tunnel
config>service>vprn>if>sap>ipsec-tunnel
During an SR OS upgrade from pre-8.0.R4 to 8.0.R4 or later, these name changes will be
automatically applied by the system.
These changes are only CLI name changes; there is no functional change to existing IPsec
features.
Following is an IPsec configuration example to depict the changes:
Pre-8.0.R4 configuration:
config>isa# info
---------------------------------------------ipsec-group 1 create
primary 1/2
no shutdown
exit
---------------------------------------------config>card# info
---------------------------------------------card-type iom3-xp
mda 1
mda-type m10-1gb-sfp-b
exit
mda 2
mda-type isa-ipsec
exit
140
Usage Notes
---------------------------------------------config>service>vprn# info
---------------------------------------------route-distinguisher 100:300
interface "toPubNet" create
address 192.168.33.1/24
sap 1/1/9 create
exit
exit
interface "public-ipsec" create
address 192.168.44.1/24
sap ipsec-1.public:100 create
exit
exit
no shutdown
---------------------------------------------ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.99.1/32
remote-ip any
exit
exit
exit
route-distinguisher 100:400
ipsec-interface "private-ipsec" create
sap ipsec-1.private:100 create
tunnel "t1" create
security-policy 1
local-gateway-address 192.168.44.99 peer
192.168.33.100 delivery-service 300
dynamic-keying
ike-policy 1
pre-shared-key "psk"
transform 1
exit
no shutdown
exit
exit
exit
interface "loop1" create
address 192.168.99.1/32
loopback
exit
static-route 192.168.22.0/24 ipsec-tunnel "t1"
no shutdown
----------------------------------------------
8.0.R4 or later configuration (changes are italicized):

config>isa# info
---------------------------------------------tunnel-group 1 create
primary 1/2
no shutdown
exit
---------------------------------------------config>card# info
----------------------------------------------
141
Usage Notes
card-type iom3-xp
mda 1
mda-type m10-1gb-sfp-b
exit
mda 2
mda-type isa-tunnel
exit
---------------------------------------------route-distinguisher 100:300
interface "toPubNet" create
address 192.168.33.1/24
sap 1/1/9 create
exit
exit
interface "public-ipsec" create
address 192.168.44.1/24
sap tunnel-1.public:100 create
exit
exit
no shutdown
---------------------------------------------ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.99.1/32
remote-ip any
exit
exit
exit
route-distinguisher 100:400
interface "private-ipsec" tunnel create
sap tunnel-1.private:100 create
ipsec-tunnel "t1" create
security-policy 1
local-gateway-address 192.168.44.99 peer
192.168.33.100 delivery-service 300
dynamic-keying
ike-policy 1
pre-shared-key "psk"
transform 1
exit
no shutdown
exit
exit
exit
interface "loop1" create
address 192.168.99.1/32
loopback
exit
static-route 192.168.22.0/24 ipsec-tunnel "t1"
no shutdown
----------------------------------------------
142
Usage Notes
Mixed-Mode
The following table lists the supported 7750 SR MDAs, IOM, and IMMs in 7450 ESS in MixedMode (7750 SR MDAs must be configured in the 7750 SR IOM3-XP for Mixed-Mode
functionality):
TABLE 31. Supported 7750 SR IOM, IMMs and MDAs in 7450 ESS in Mixed-Mode
Alcatel-Lucent
Part #
Description
3HE00021AA
3HE00023AA
3HE00030AA
1-port 10GBASE-LW/LR MDA w/ optics - Simplex SC
3HE00031AA
1-port 10GBASE-EW/ER MDA w/ optics - Simplex SC
3HE00032AA
3HE00033AA
3HE00037AA
3HE00038AA
3HE00043AA
3HE00044AA
3HE00048AA
1-port OC-192c/STM-64c MDA w/SR-1/I-64.1 optic - Simplex SC
3HE00049AA
1-port OC-192c/STM-64c MDA w/IR-2/S-64.2 optic - Simplex SC
3HE00071AA
3HE00074AA
3HE00101AB
20-port 10/100/1000TX MDA - RJ45
3HE00707AA
3HE00708AA
3HE00709AA
1-port OC-192c/STM-64c MDA w/LR-2/L-64.2 optic - Simplex SC
3HE00710AA
1-port 10GBASE-ZW/ZR MDA w/ optics - Simplex SC
3HE00714AA
3HE01197AA
7750 SR Versatile Services Module (VSM)
3HE01364AA
4-port Channelized OC-3/STM-1 (DS0) ASAP MDA - SFP
3HE01616AA
3HE02021AA
1-port 10GBASE + 10-port GIGE MDA
3HE02499AA
1-port Channelized OC-12/STM-4 ASAP MDA
3HE02500AA
3HE02501AA
3HE03078AA
1-port Channelized OC-3/STM-1 CES MDA
3HE03079AA
7750 SR 4-port CH OC3-1/STM-1 CES SFP MDA
3HE03611AA
3HE03612AA
3HE03613AA
7750 SR 20-port GE - XP - Copper/TX MDA
3HE06318AA
143
Usage Notes
Alcatel-Lucent
Part #
144
Description
3HE03619AA
3HE03622AA
3HE03623AA
3HE03624AA
7750 SR 48-port GE fixed port IOM (IMM)
3HE03625AA
7750 SR 48-port GE copper port IOM (IMM)
3HE03685AA
7750 SR 2-port 10GBASE - XP - XFP MDA
3HE03686AA
3HE04179AA
7750 SR 10GBASE Tunable ZW/R MDA
3HE04272AA
7750 SR 1-port OC-12/STM-4 CES MDA
3HE04274AA
3HE04741AA
3HE04743AAAB
7750 SR 12-port 10G Ethernet SFP+ IMM
3HE04922AA
7750 SR / 7450 ESS Multiservice ISAa
3HE05053AAAB
7750 SR 1-port 100G Ethernet CFP IMM
3HE05055AA
7750 SR 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable

IMM
3HE05142AA
7750 SR 7450 ESS Multiservice ISA-E (no encryption)a
3HE05160AA
7750 SR 48-port 10/100/1000 - XP MDA - mini-RJ21
3HE05553AA
3HE05553BA
3HE05813AA
3HE05813BA
7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM L3BQ
3HE05814AA
3HE05814BA
3HE05895AA
3HE05895BA
7x50 48-port GE fixed port IOM (IMM) - L3BQ
3HE05896AA
3HE05896BA
7x50 48-port GE copper port IOM (IMM) - L3BQ
3HE05898AA
3HE05898BA
3HE05899AA
3HE05899BA
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
Usage Notes
Alcatel-Lucent
Part #
Description
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
3HE06318AA
3HE06320AA
3HE06326AA
3HE06326BA
7x50 48-port GE Multicore-CPU SFP IMM - L3BQ
3HE06326CA
3HE06428AA
3HE06429AA
3HE06430AA
3HE06431AA
3HE06432AA
7750 SR 10-port GE SFP HS-MDAv2
3HE06721AA
3HE06721BA
3HE06798AA
3HE06798BA
7750 1-port 40GE DWDM Tunable IMM - L3BQ
3HE06798CA
3HE07158AA
3HE07158BA
3HE07158CA
3HE07159AA
3HE07159BA
3HE07159CA
3HE07282AA
7750 SR 2-port 10GE XFP + 12-port GE SFP -XP MDAa
3HE07283AA
7450 ESS 2-port 10GE XFP + 12-port GE SFP -XP MDA
3HE07284AA
7750 SR 12-port GigE - XP - SFP MDAa
3HE07285AA
7450 ESS 12-port GigE -XP -SFP MDA
3HE07303AA
3HE07303BA
3HE07303CA
3HE07304AA
3HE07304BA
7x50 6-port 40GE FP3 QSFP IMM - L3BQ
3HE07304CA
3HE07305AA
3HE07305BA
145
Usage Notes
Alcatel-Lucent
Part #
Description
3HE07305CA
3HE08019AA
3HE08019BA
7x50 1-port 100GE DWDM Tunable FP3 IMM - L3BQ
3HE08019CA
3HE08020AA
3HE08020BA
7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L3BQ
3HE08020CA
3HE08174AA
3HE08174BA
7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3BQ
3HE08174CA
3HE08175AA
3HE08175BA
7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3BQ
3HE08175CA
3HE08426AA
7750 SR IOM3-XP-C
3HE09279AA
3HE09279BA
7x50 48-port GE MultiCore SFP IMM - L3BQ
3HE09279CA
a. 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.
Multiservice
Integrated
Services Adapter
The following tables list IOM support for MS-ISA and MS-ISA-E applications:
TABLE 32. Compatible 7750 SR IOMs for MS-ISA Applications
Application Assurance (isa-aa)a

Retransmission and Fast Channel
Change
(Video ISA)
Video Quality Monitoring
Video Dual Stream Selection
Local/Zoned Ad Insertion
(Video ISA)
Tunnel Services, including IPsec
(isa-tunnel)a
146
IOM-20g-b
IOM2-20g
IOM3-XP/-b/
-c
Yb
Yb
Usage Notes
TABLE 32. Compatible 7750 SR IOMs for MS-ISA Applications (Continued)

Network Address Translation (isa-bb)
L2TP LNS Service (isa-bb)
WLAN-GW (isa-bb)
Arbor TMS (isa-tms)
a. Application Assurance, and Tunnel and IPsec services are also supported on the 7750 SR-c12.
b. MS-ISA only. Not supported on MS-ISA-E.
TABLE 33. Compatible 7450 ESS IOMs for MS-ISA Applications

IOM-20g-b
IOM3-XP/-B/
-C
(isa-aa)
Retransmission and Fast
Channel Change
(Video ISA)
BGP VPWS
Upgrading from
7710 SR-c12 to an
7750 SR-c12
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.
The 7750 SR-c12 system shares the same chassis (with a different label ) as the 7710 SR-c12
system. It is possible to upgrade from 7710 SR-c12 to 7750 SR-c12 to make use of the increased
capacity and the 10G support. In order to achieve this, the following parts need to be upgraded:
CCM upgraded to CCM-XP
CFM upgraded to CFM-XP
MCM upgraded to MCM-XP
Power Entry Module (PEM) upgraded to higher powered PEM-3 modules
The Fan Tray upgraded to the new Hi-Flow Fan Tray.
The 7710 SR-c12 system configuration cannot be used on 7750 SR-c12 without editing the
configuration files. Contact your local support team to convert 7710 SR-c12 configuration files
for use in a 7750 SR-c12 after the hardware has been upgraded.
Most of the CMAs and MDAs supported on 7710 SR-c12 are supported on 7750 SR-c12. Note
that the following MDAs which are supported on 7710 SR-c12 are not supported on 7750 SRc12:
147
Usage Notes
Compact Flash
Devices
Application
Assurance
IPsec
148
3HE00025AA
7750 5-port GigE MDA - SFP
3HE00101AB
7750 SR 20-port 10/100/1000 MDA
3HE00708AA
7750 SR 20-port GIGE SFP MDA
3HE01615AA
7750 5-port GigE MDA - SFP Rev B
Only Alcatel-Lucent-sourced Compact Flash devices for the SR OS are supported.
In Release 10.0.R1 and higher, it is recommended that the compact flash in the CF3 slot be
at least 1GB. The extra compact flash space is intended to support customers who may
want to keep more than one copy of the software.
It is recommended to use cf1: or cf2: for event logs
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-bucketbandwidth 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
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.
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.
Usage Notes
IPsec
Compatibility
The following tables list software and hardware tested for compatibility with IPsec
services:
TABLE 34. 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 35. 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
SNMPv3 user authentication and privacy keys in the config>system>security>user username>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]
TCP
Authentication
Extension
Keychains with no active entries will keep LDP and BGP peerings down. [57917]
Disallowed IP
Prefixes
The following IP address prefixes are not allowed by the unicast routing protocols and the
Route Table Manager and will not be populated within the forwarding table:
Management
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.
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, when an entry is deleted from a given line card (i.e.
an entry is deleted, or a given filter policy is no longer used on a given line card), the CPM
resets that entrys counters to zero. If the counters are required, they should be retrieved
prior to such a configuration change.
149
Usage Notes
HW/Platform
System
150
Since ingress and egress filter policies support different functionality (actions and/or match
criteria), deploying the same filter policy on both ingress and egress is not recommended.
Using a filter policy on a line card or in a direction that does not support a given match
criterion may result in an undesired 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.
When a filter policy with a conditional action (for example, drop packet-length) is used
on a line card that does not support the given conditional action or is used in a direction that
does not support the given conditional action, the condition is ignored; if a packet matches
an entry with a conditional action, the action is executed without the condition being
applied (for example, drop is executed instead of drop packet-length).
Filter policy Time-of-Day (ToD) functionality is planned to be deprecated in a future

release. Starting from Release 11.0.R1, all newly introduced filter policy functionality is no
longer supported in combination with ToD functionality. It is recommended not to
configure a filter policy that has both ToD and Release 11.0.R1 or newer filter policy
enabled.
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 which is a different behavior
from prior releases. [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]
For Releases 4.0 and later, redundant configurations with a mixture of SF/CPMs and
SF/CPM2s in the same chassis is supported. This change simplifies and eases the transition
from the SF/CPM to the SF/CPM2 in a maintenance window. Running with a mixture of
SF/CPM versions for a prolonged period, however, is not recommended.
Replacing an MS-ISA with another MDA type (i.e., 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 7450 ESS, 7950 XRS, and 7750/7710 SR routers support qualified pluggable optic
modules only. Refer to the current Alcatel-Lucent price list for supported modules. Thirdparty optics are not supported.
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.
Downgrading from chassis mode C to chassis mode B may require the removal of IPv6
addresses from the BOF configuration. [133960]
Usage Notes
The special characters | and > can no longer be used inside environment alias strings.
Additionally, the special characters / and \ cannot be used as the first character inside an
alias string.
Starting in Release 10.0.R3, a pw-port needs to be created first (with encap-type

dot1q/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]
RADIUS
Release 10.0 was the last SR OS release that supported RADIUS-based Auto-Discovery
for VPLS. Contact your account team regarding further assistance about this change.
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]
APS
It is recommended 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.
For SONET/SDH ports belonging to APS groups that have a very large difference in the
transmission delay between the working and protect circuits, it is recommended 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.
ATM
7750 SR, 7450 ESS in mixed-mode and 7710 SR allow configuration of user traffic on
reserved ATM Forum UNI specification VCI values (VCIs from 0 to 31 inclusive). It is
recommended not to configure 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:
CLI
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 sublayer will accept packets with or without leading zeros in the protocol field even though the
7750 SR, 7450 ESS in mixed-mode and 7710 SR do not advertise the protocol field
compression (PFC) option during LCP negotiation. [25996, 29923]
151
Usage Notes
It is recommended 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]
Reducing the interval/timeout timers much below default values is not recommended for
OSPF, IS-IS, PIM, BGP, LDP and RSVP to ensure stability under transitional events like a
CFM switchover. [56792, 58891]
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. It is recommended 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-authenticationtype 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]
BGP
It is recommended that the local address be configured when a box has multiple BGP peers
to same node. [113614]
The static blackhole route should be created prior to receiving routes or creating the policy
in combination with autobind GRE. [160617]
The current bypass binding selection logic for Release 7.0 and higher is the following:
Routing
IS-IS
MPLS/RSVP
For non-Strict environment

a) Manual CSPF disjoint bypass
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 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]
152
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
Usage Notes
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.
IP Multicast
QoS
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]
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.
Alcatel-Lucent recommends CPM3 or higher for PIM adjacency scale beyond 1,500.
To execute mtrace and mstat with protocol-protection enabled (config>security>cpuprotection), IGMP must be enabled on incoming interfaces. [160402]
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, it is recommended 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]
Profile mode queues in FP3 platforms use two (2) offered stat counters as opposed to four
(4) in non-FP3 platforms. This means FP3 unicast profile mode queues provide offereduncolored and a combined in+out profile offered-colored stats. FP3 multicast profile mode
queues provide a combined offered-combined stats and an offered-mcast-managed stats 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 stats 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, UncoloredPacketsOffered. The show command
output displays offered-managed and offered-uncolored as separate stats for profile-mode
non-FP3 multicast queues. The show command output also displays different stat counters
based on platform type.
153
Usage Notes
On LDP interfaces and targeted-session keepalive commands, it is recommended 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 export/import 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 exported/imported. The workaround is to ensure that the configuration files do not
contain policy mis-configurations or mismatches between LDP and the policy manager.
The use of 256M and 1G compact flash cards for DHCP or subscriber persistency for
Release 7.0.R1 and beyond should be discontinued. A 4G or 8G compact flash is
recommended.
DHCP persistency should not be configured to use Compact Flash drives formatted with
the newer Reliance file system. [50940]
In Release 10.0.R1 and higher, a vendor-support option has been added to the Diameterbase configuration of a Diameter policy. The default is set to 3gpp. After an upgrade from
Release 9.0 or earlier, the vendor-support option should be explicitly configured if it is
different from 3gpp.
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 for the active configuration, but needs to be manually updated if the server
is used for multiple applications.
DHCPv4 On-Demand Subnet Assignment (ODSA) is no longer supported starting with

Release 11.0.R7.
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]
Mirror Service
CLI commands entered under the debug mirror-source sub-menu are now automatically
synchronized with the standby CPM/CFM. These commands must no longer be placed in
the CLI script file that is executed with the switchover-exec command. [105122]
Time-of-Day
Suites
In a TOD suite, items can be defined that cannot be applied to all SAP types: for instance,
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
LDP
Subscriber
Management
154
Usage Notes
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 ingress an 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.
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).
BGP AutoDiscovery
On the 7450 ESS without mixed mode, only the L2-VPN address family is supported by
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.
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.
155
Software Upgrade Procedures

The following sections contain information for upgrading to the 11.0.R20 software version. In
particular, there are sections that describe the following:
-
Software Upgrade Notes on page 156

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 on page 162

Information on upgrading MS-ISA to a new AA-signature load.
ISSU Upgrade Procedure on page 166

Procedure for performing an ISSU to 11.0.R20 including information on applicability
of ISSU for earlier versions.
Standard Software Upgrade Procedure on page 180

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 11.0.R20.
Note:
An admin reboot upgrade is required for the following:
All 7450 ESS-6/6v chassis running Release 6.1.R2 or earlier
During an upgrade process to SR OS Release 9.0.R23, 10.0.R13, 11.0.R4 or later on all

7450 ESS-6/6v chassis and all 7750 SR or 7450 ESS chassis with SF/CPM1
Note:
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.
In the sections below, the following terminology is used:
156
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 command 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.
DHCP
When upgrading from Release 10.0.R10 through 10.0.R15 or from Release 11.0.R1
through 11.0.R7 to Release 11.0.R8 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 esm-relay 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.
Upgrading to
Release 11.0.R7 or
Higher
Starting with Release 11.0.R7, configuration changes are required for TACACS+ servers to
authorize global commands. Global commands such as info, exit, etc., except the command
logout, 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
Release 11.0.R1 or
11.0.R2
The parameter port-forwarding-dyn-block-reservation was introduced in Release 11.0.R1

and was incorrectly allowed to be configured for type L2-aware NAT pools. From 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 "portforwarding-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]
CLI
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]
ISSU
Prior to Major ISSU, if Lawful Intercept (LI) mirror is active on any filter and the LI filter
lock state is locked, it should first be changed to li-filter-lock-state unlocked-for-allusers, and upon completion of ISSU, set back to its prior value. [162967]
After performing Major ISSU from Release 10.0.R7 or lower to Releases 11.0, any existing
unnumbered IS-IS interface type is changed to broadcast and cannot be used as a TE link in
MPLS. The workaround is to change the interface type under IS-IS to no interface-type,
which will set the interface to point-to-point.
After performing Major ISSU to Releases 11.0, any existing unnumbered OSPF interface
type is changed to broadcast and cannot be used as a TE link in MPLS. The workaround is
to change the interface type under OSPF to no interface-type, which will set the interface
to point-to-point.
Starting with Release 10.0.R4 and 11.0.R1, when the system starts Major or Minor ISSU
procedures, MPLS will automatically be put into maintenance mode. In maintenance
mode, the MPLS module will permit LSPs to continue normal operation, prevent the node
157
from issuing new LSPs or a Make-Before-Break (MBB) path for existing LSPs, and reject
requests for new LSPs or MBB paths of existing LSPs sent by RSVP neighbors. The MPLS
module will automatically exit the new maintenance mode when the Major or Minor ISSU
is completed.
Upgrading to
Release 11.0.R4 on
XRS-20
The tmnxPortID mapping has changed for the 7950 XRS-20 platform. Refer to TIMETRATC-MIB for specific details. 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.
Upgrading SR OS
for R-VPLS:
R-VPLS does not support configuration of line card MAC filters. This restriction is now
properly enforced starting with Releases 8.0.R18, 9.0.R15, 10.0.R4, or 11.0.R1. 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
Consideration
when Upgrading
from Release
10.0.R4 or higher
to Release 11.0.R1
or higher
Starting with Release 11.0.R1, SR OS enforces the rule that a single CLI filter policy entry
should not exceed the allowed hardware resources (Filter Policies Known Limitation
142472). Operators are advised to verify that a 10.0 configuration that uses match list in
filter policies does not exceed the recommended limit prior to an upgrade. Failure to do so
will result in configuration failure during an upgrade if the entry exceeds the enforced
limits. The enforced rule allows 2000 hardware sub-entries per line card filter policy entry
and 256 hardware sub-entries per CPM filter policy entry (approx. 25% margin atop
Release 10.0.R4 recommended/supported limits as outlined by Known Limitation 142472).
Upgrading to
Release 11.0.R1 or
higher
Support for the read-only radiusServerTable (and corresponding RadiusServerEntry

objects) and read-only tacplusServerTable (and corresponding TacplusServerEntry objects)
in the TIMETRA-SYSTEM-MIB has been removed in Release 11.0.R1 onwards. The
alternative 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 upgrades, backing up images, etc. 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 or ISSU Upgrade Procedure in this
158
document. Releases prior to Release 11.0.R1 do not know about the support.tim file and
hence the synchronize command will not copy it.
The following IP interface ingress statistics previously introduced in Release 9.0.R1 for
FP2 or later generation cards have become conditional to the use of the enable-ingressstats command on the interface both for CLI and SNMP:
-
IP offered packet counter (existing - will now only maintain an IPv4 packet count)
IP offered octet counter (existing - will now only maintain an IPv4 octet count)
IP uRPF failed packet counter (existing - will now only maintain an IPv4 packet
count)
IP uRPF failed byte counter (existing - will now only maintain an IPv4 packet count)
Upgrading to
Release 10.0.R1 or
higher
It is recommended that the compact flash for software in the CF3 slot be at least 1 GB. The
extra compact flash space is intended to support customers who may want to keep more
than one copy of the software.
Upgrading to
Release 9.0.R1 or
higher
In Release 9.0.R1, the default action for most log events was changed from generate to
throttle. This means that many more events are subject to (and count towards) the throttle
rate. The default throttle rate was also changed in Release 9.0.R1 from 500 to 2000
[91135], but operators who were using a custom throttle rate in Release 8.0 or earlier (with
a small number of events subject to throttling) may need to adjust it upwards after
upgrading to Release 9.0.R1 and higher in order to take into account the large number of
events now subject to throttling.
Management
The system no longer reports change events (system events 2006 through 2009) under the
main event source. To continue receiving these events in the same manner as before
Release 9.0.R1, change the log's "from main" to "from main change". [136968]
Upgrading from
Release 9.0.R3
In Release 9.0.R3, the allow-unmatching-subnets flag was introduced to allow martian /0

subnets together with the regular subnet on subscriber interfaces. In Release 9.0.R4 and
higher, this flag is not allowed in combination with the unnumbered parameter. If both
flags are present in Release 9.0.R3, the allow-unmatching-subnets flag should be
manually removed from the configuration file. [114747]
Upgrading
Application
Assurance from
CPM with Release
9.0.R4 or higher
After the Application Assurance upgrade, the isa-aa card may no longer be collecting card
level protocol statistics. This can be re-enabled by toggling the collection off, and then
back on.
Upgrading from
Release 9.0.R4 or
9.0.R5 to 9.0.R6 or
higher
IPv6 traffic locally routed between ESM subscribers configured for application assurance
may not be properly routed until all IOMs have been upgraded. To avoid this issue, it is
recommended to shut down the application-assurance group until all IOMs have been
upgraded.
159
Upgrading
Application
Assurance to
Release 8.0.R5 or
higher
When upgrading from a previous major release, ensure that protocols referenced in any
configuration (e.g. app-filters, aa-sub statistics) are supported by the new release isa-aa.tim
file. References to unsupported protocols will result in a failure to load the configuration
file.
File Version Check
If the file version check command is performed on images for Release 8.0.R1 or higher
prior to upgrading, the command will fail with a Sector 0 corrupted error message. This is
due to the use of a new file compression scheme in Release 8.0.R1 or higher. The images
can still be validated by using the md5sum utility. Software releases prior to Release
8.0.R1 that mention 93667 in their Resolved Issues section will not have this issue.
Upgrading CPU
Protection from
Release 7.0 to 8.0
or later
160
Considerations for CPU Protection for upgrade to Release 8.0.R1 or higher:
If a config being executed in Release 8.0.R1 or higher contains no policy 254 or no

policy 255, then that statement will be ignored and a warning event will be created.
Existing policies will automatically have the new out-profile-rate with the default value
added to them.
Release 7.0 or prior configurations contain policy 1 create and exit in the saved config,
even though the operator never created or modified policy 1. When this type of
configuration is loaded under Release 8.0.R1 or higher, it will cause policy 1 to be created
with the new policy default parameters.
In the case where a user upgrades from a previous release to Release 8.0.R1 or higher, and
they were using only the cpu-protection defaults from the previous release, when the config
is loaded in Release 8.0.R1 or higher, all the interfaces (except video interfaces) will use
the new policies 254 and 255 (no interfaces will point to policy 1). Video interfaces will
continue to use no cpu-protection policy by default.
If a user upgrades to Release 8.0.R1 or higher from a Release 6.0/7.0 configuration that
contains custom policies with default rate values, the new default values will be applied to
those custom policies. The user should examine and possibly modify the rate values in
their custom policies after the upgrade to Release 8.0.R1 or higher.
If a user upgrades to Release 8.0.R1 or higher from a Release 6.0/7.0 configuration with
SAPs that reference cpu-protection 1 mac-monitoring then those SAPs will not
automatically migrate to the new default access policy 254. The user will have to update
the SAPs to use policy 254 (or adjust the rate values of policy 1 as a short term solution
until they can migrate SAPs to policy 254).
In order to have the same strict discard behavior on network interfaces by default as in
releases prior to Release 8.0.R1, the user needs to manually change the overall-rate from
the default value of max to a value of 3000 in policy 255. [83018, 92746]
If a user upgrades from Release 7.0 to Release 8.0.R1 or higher and they had defined
custom policies 254 and/or 255, then:
-
Those custom policies 254 and 255 will retain the same settings for any parameters
that the user had explicitly configured in Release 7.0
Any parameters within customized policies 254/255 that were left as their default
values will take on the new default values after upgrade to Release 8.0.R1 or higher.
Policy 255 will have the overall-rate changed from a default of 6000 to a default of
max.
An out-profile-rate parameter will be added to policies 254/255 and the value will be
equal to the default out-profile-rate for profiles 254/255. The user will have to modify
the out-profile-rate to an appropriate value.
All the interfaces that had been using custom policies 254 and 255 will continue to
use those same policies in Release 8.0.R1 or higher.
Any interfaces that had been using the default policy in Release 7.0 will instead use
the customized policies 254 and 255 in Release 8.0.R1 or higher (or no policy for
video interfaces).
The following actions are recommended before upgrading to Release 8.0.R1 or higher if using
policies 254 or 255 in a Release 7.0 or prior configuration. This will ensure that all custom
settings are preserved, and that any interfaces that were using the CPU Protection defaults in
Release 7.0 will use the new defaults:
Upgrading from
Release 6.1 or
earlier to 11.0.R20
1.
Select a new ID for policies 254 and 255, and replicate the policy config into those new
policies
2.
Reassign each interface that was using policies 254 and 255 to point to the new policy IDs
3.
Delete policies 254 and 255.
The following note applies to upgrading from SR OS Release 6.1 or lower to SR OS Release
11.0.R20.
Application
Assurance
Release 7.0 introduced several Application Assurance-related CLI configuration changes

that replace existing CLI commands with new commands. On an upgrade, the old
configuration is automatically converted to the new configuration; old commands are
rendered obsolete. Executing admin save after an upgrade to replace pre-Release 7.0
configuration with the new configuration is recommended. Details on the changes
introduced are listed in the Application Assurance section under Enhancements of this
document.
Compact Flash
In a system where DHCP or subscriber persistency is enabled, a higher density compact

flash card (4G or larger) needs to be in the system before an upgrade is performed to ensure
the new DHCP or subscriber persistency file can be written.
CLI
The MDT CLI tree under config>service>vprn>pim has been deprecated. The old
configurations will be automatically converted to the new mVPN configurations under
config>service>vprn>mvpn when upgrading to Release 8.0.R1 or higher. The
show/clear>router service-id>pim data-mdt commands have been replaced by the
show/clear>router service-id>pim>s-pmsi commands.
VRRP
Starting with Release 8.0.R1, the CLI commands for priority 0 explicit are rejected in the
following six VRRP policy sub-menus. Prior to upgrading to this release, remove these
commands from the configuration file:
config>vrrp>policy>priority-event>port-down
config>vrrp>policy>priority-event>lag-port-down>number-down
161
config>vrrp>policy>priority-event>host-unreachable (IPv4 and IPv6)
config>vrrp>policy>priority-event>route-unknown (IPv4 and IPv6)
LDP
The LDP/T-LDP hello and keepalive timeout parameter is now enforced in CLI to a value
higher or equal to three (3) seconds. Note, however, that if the user entered a combination
of a timeout lower than three (3) and a value of the factor higher or equal to three (3), the
values will be swapped by the CLI parser. [76900]
OAM
Multiple local MEPs configured on service SAPs used in a combination with a "remotemepid <mep-id> remote-mac <unicast-da>" must not exist in any configuration. This may
prevent the configuration file from loading on reboot or upgrade. Unicast CCM must only
be used in point-to-point environments where a single MEP exists in the service which
utilizes a remote-mep configured with a unicast remote-mac <unicast-mac> for that
association. Combinations that includes multiple local MEPs in the service and a unicast
remote-mep under the association are not supported. This is an invalid configuration and
operational behavior cannot be guaranteed. Upgrading from Release 10.0.R1 through
Release 10.0.R3 to 10.0.R4 and beyond will stop the configuration from loading. In some
instances, the loading of the configuration of Release 10.0.R1 through 10.0.R3 will be
prevented until the offending statements are removed. [145439]
AA Signatures Upgrade Procedure

This section describes the AA Signatures Upgrade Procedure which can be used to upgrade MSISAs 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 criteria does not apply, the Standard Software Upgrade Procedure on page 180 must
be performed. This section does not apply to 7710 SR, 7750 SR-1 or 7450 ESS-1.
Note:
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.
162
Step 1
Backup 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 be 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:\10.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.
STEP 4
Use admin redundancy synchronize boot-env to synchronize the boot

environments between the active and standby CPM/CFMs.
Load new Image for MS-ISA

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 MS-ISA cards status.
A:ALU-ABC>show>app-assure# version
==============================================================================
Versions of isa-aa.tim in use
==============================================================================
CPM : TiMOS-M-10.0.R2
1/2 : TiMOS-M-10.0.R1
3/2 : TiMOS-M-10.0.R1
==============================================================================
163
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 MS-ISAs to Load the New Image

The MS-ISAs 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 MS-ISAs after 2 hours. The Comments field in the show card
state output displays the time until the system resets the MS-ISA in the ISSU state.
The timing and order of the MS-ISA resets should be sequenced to maximize the effectiveness
of any redundancy. When redundancy is deployed, protecting (standby) MS-ISAs should be
reset first, and admin activity switch should be forced first (config mda <m>/<n> shutdown)
before an active MS-ISA is reset.
Use shutdown mda <m>/<n> to shut down an MS-ISA
Use clear mda <m>/<n> to reset an MS-ISA
Use no shutdown mda <m>/<n> to enable an MS-ISA
Use show application-assurance version to verify the isa-aa signatures

version loaded on the CPM/CFMs and the MS-ISAs
The sample output below shows the operational state transitions for a single Application
Assurance group with one (1) active and one (1) protecting (standby) MS-ISA.
1. Before reset starts:
==============================================================================
==============================================================================
1/2 : TiMOS-M-10.0.R1
3/2 : TiMOS-M-10.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
164
==============================================================================
2. After the standby MS-ISA is reset and comes back up:

==============================================================================
==============================================================================
1/2 : TiMOS-M-10.0.R2
3/2 : TiMOS-M-10.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
up/standby
...
3
2
isa-aa
isa-ms
up
ISSU/active
==============================================================================
3. After the MS-ISA activity switch (shutdown of active card to force activity switch):
==============================================================================
==============================================================================
1/2 : TiMOS-M-10.0.R2
3/2 : TiMOS-M-10.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
up/active
...
3
2
isa-aa
isa-ms
down
ISSU/standby
==============================================================================
4. After the newly inactive MS-ISA is reset, comes back up (clear command executed) and is
re-enabled (no shutdown executed):
==============================================================================
==============================================================================
1/2 : TiMOS-M-10.0.R2
165
3/2 : TiMOS-M-10.0.R2
==============================================================================
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
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 MS-ISAs 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 (i.e., admin reboot upgrade). See the
ISSU sub-section of the Known Limitations on page 183 for details.
On routers running 11.0.R4 to 11.0.R19 for Minor ISSU with redundant CPMs/CFMs
(not applicable on the 7710 SR-c4, 7750 SR-1, 7750 SR-c4 or 7450 ESS-1), except
for the 7950 XRS, which only supports Minor ISSU from 11.0.R5 onwards
On routers running 10.0.R4 to 10.0.R20 for Major ISSU with redundant CPMs only
(not applicable to the 7750 SR-1, 7450 ESS-1 or on CFM-based platforms such as the
7710 SR-c4/c12 and 7750 SR-c4/12)
If any of the above criteria do not apply, the Standard Software Upgrade Procedure on page 180
must be performed.
166
ISSU limitations listed under Known Limitations on page 183 should be taken into account for
planning purposes before the ISSU is performed.
Note:
CONSOLE device 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 CPM/CFMs prior to starting the
ISSU.
The ISSU procedure is split into two (2) phases.
Phase A Common to both Minor ISSU and Major ISSU
Phase B Different for Minor ISSU and Major ISSU. Make sure to follow the correct
Phase B for your upgrade scenario.
Phase A
Preparation and CPM/CFM Upgrade
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.
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.
167
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:\11.0.R20. 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.
STEP 5
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.
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.
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 know about the support.tim file and hence, the
synchronize command will not copy it.
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 the start of ISSU, the cards will look like the following for systems with CPMs:
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
3
iom-20g-b
iom-20g-b
up
up
4
iom-20g-b
iom-20g-b
up
up
5
iom-20g-b
iom-20g-b
up
up
A
sfm-200g
sfm-200g
up
up/active
B
sfm-200g
sfm2-200g
up
up/standby
168
==============================================================================
The cards will look like the following for systems with CFMs:
==============================================================================
Card Summary
==============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Card-type
Card-type
State
State
-----------------------------------------------------------------------------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.
The cards for systems with CPMs will look like the following:
A:router1# admin reboot standby now
==============================================================================
Card Summary
==============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Card-type
Card-type
State
State
-----------------------------------------------------------------------------2
iom-20g-b
iom-20g-b
up
up
3
iom-20g-b
iom-20g-b
up
up
4
iom-20g-b
iom-20g-b
up
up
5
iom-20g-b
iom-20g-b
up
up
A
sfm-200g
sfm-200g
up
up/active
B
sfm-200g
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
==============================================================================
Slot Provisioned Equipped Admin Operational
Card-type Card-type State State
-----------------------------------------------------------------------------2 iom-20g-b iom-20g-b up up
3 iom-20g-b iom-20g-b up up
A sfm-200g sfm-200g up up/active
B sfm-200g sfm2-200g up synching/standby
169
==============================================================================
When the standby CPM/CFM has completely synchronized, the standby CPM/CFM will
indicate a state of ISSU, as in this example for systems with CPMs.
==============================================================================
Card Summary
==============================================================================
-----------------------------------------------------------------------------2 iom-20g-b iom-20g-b up up
A sfm-200g sfm-200g up up/active
B sfm-200g sfm2-200g 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 Completion of the ISSU

Phase B of the ISSU procedure is different for Minor ISSU and Major ISSU.
Phase B (Minor)
Minor ISSU Completion of the ISSU
The following steps describe the rest of the ISSU procedure for Minor ISSU. For Major ISSU,
skip ahead to Phase B - Major ISSU on page 174.
170
STEP 8
(Minor ISSU) Switchover the CPM

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.
In the sample output below, the switchover is initiated from the CONSOLE on Slot A. The
CPM/CFM in Slot A reboots and the boot up messages are displayed:
A:router1# admin redundancy force-switchover
TiMOS-C-5.0.Rx cpmboth/hops ALCATEL SR 7710 SR 7750 ESS 7450 Copyright (c)
2000-2007 Alcatel-Lucent.
All rights reserved. All use subject to applicable license agreements.
Built on ddd mmm d hh:mm:ss PST 2007 by builder in /rel5.0/panos/main
<...>
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 (i.e., one PC with a serial port), the console session must be reestablished 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 command
show card 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
3 iom-20g-b iom-20g-b up ISSU
A sfm-200g up down/standby
B sfm-200g sfm2-200g up up/active
==============================================================================
==============================================================================
Card Summary
==============================================================================
171

A sfm-200g sfm-200g up synching/standby
==============================================================================
==============================================================================
Card Summary
==============================================================================
A sfm-200g sfm-200g 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 IOMs and IMMs to Load the New Image
The IOMs and IMMs must now be reset to load the new image. This step is not necessary for
the 7750 SR-c12 or the 7710 SR-c12. If the cards will be Soft Reset (see below), refer to the
Soft Reset sub-section of the Known Limitations in the Release Notes 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 clear card n soft hard-reset-unsupported-mdas to soft reset an IOM or IMM. The
IOM/IMM data path and MDAs are not reset in Soft Reset compatible cases, resulting in a
very brief service interruption.
If the soft reset is blocked, then use clear card n to hard reset the IOM. This will reboot
the IOM and its MDAs and ISAs, causing an outage for the duration of the reboot
Note:
The system does not allow cards to run in an ISSU state indefinitely; the system
automatically hard resets the IOMs/IMMs after two (2) hours. The Comments field in the
show card state output displays the time until the system resets the IOM/IMM in the ISSU
state.
172
Note:
It is recommended to Soft Reset no more than one IOM/IMM at a time to ensure that the
IOM/IMM download process does not impact control plane protocols. Wait for the
operational state to be up before proceeding to the next IOM/IMM.
Note:
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 IOM/IMM.
B:SoftReset1# clear card 4 soft
B:SoftReset1# show card
==============================================================================
Card Summary
==============================================================================
4 iom-20g-b up soft reset
A sfm-400g sfm2-400g up up/standby
B sfm-400g sfm-400g up up/active
========================================================================
When the IOM/IMM is in the up state, it will have the new image so it will no longer have an
ISSU operational state.
==============================================================================
Card Summary
==============================================================================
A sfm-400g sfm2-400g up up/standby
B sfm-400g sfm-400g up up/active
==============================================================================
173
The timing and order of the IOMs and IMMs resets should be sequenced to maximize the
effectiveness of any redundant interfaces (LAGs, VRRP, etc.) spanning IOM/IMM, 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 IOM/IMM is in the up state, it will have the new image so it will no longer have an
ISSU operational state.
==============================================================================
Card Summary
==============================================================================
-----------------------------------------------------------------------------2 iom-20g-b iom-20g-b up up
==============================================================================
When all of the IOMs and IMMs 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 ISSU
174
Phase B (Major)
Major ISSU Completion of the ISSU
The following steps describe the rest of the ISSU procedure for Major ISSU. For Minor ISSU,
skip back to Phase B - Minor ISSU on page 170.
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 2012/05/30 16:21:03.83 EDT MAJOR: CHASSIS #2001 Base Card B
"Class CPM Module : failed, reason: Issu Unsupported Scenario, No Reload"
121 2012/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 s/w image
become the active CPM.
NOTE: 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 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.
The following example shows a particular card and mda configuration, along with the resulting
ISSU hard/soft reset reasons.
A:Dut-A# show card
==============================================================================
Card Summary
==============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
-----------------------------------------------------------------------------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
8
iom2-20g
iom2-20g
up
up
9
iom2-20g
iom2-20g
up
up
10
iom3-xp
iom3-xp
up
up
A
sfm3-12
sfm3-12
up
up/active
B
sfm3-12
sfm3-12
up
ISSU/standby
175
==============================================================================
A:Dut-A# show mda
==============================================================================
MDA Summary
==============================================================================
Slot Mda
Provisioned
Equipped
Admin
Operational
Mda-type
Mda-type
State
State
-----------------------------------------------------------------------------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 s/w image X to s/w
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 shutdown (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
176
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) IOM/IMM 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 routines
are available. If the operator attempts to use a command that is invalid during this phase, they
will be given 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 IOM/IMM cards are reset so that the IOMs/IMMs 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 IOM/IMM as described in
previous steps).
Note that 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 s/w image first takes over:
TiMOS-C-11.0.B1-106 cpm/hops ALCATEL SR 7750 Copyright (c) 2000-2012 AlcatelLucent.
All rights reserved. All use subject to applicable license agreements.
Built on Mon May 28 18:44:43 PDT 2012 by builder in /rel11.0/b1/B1106/panos/main
KANHWSYNC1 - Dut-A
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/2012 16:00:33
177
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)
8
iom2-20g
up
soft reset
(not equipped)
9
iom2-20g
up
provisioned
(not equipped)
10
iom3-xp
up
soft reset
(not equipped)
A
sfm3-12
up
down/standby
(not equipped)
B
sfm3-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 the Soft Resets are completed.
==============================================================================
Card Summary
==============================================================================
Slot
Provisioned Type
Admin Operational
Comments
State State
-----------------------------------------------------------------------------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
5
iom2-20g
up
soft reset
7
imm3-40gb-qsfp
up
booting
8
iom2-20g
up
soft reset
9
iom2-20g
up
booting
10
iom3-xp
up
soft reset
A
sfm3-12
up
down/standby
B
sfm3-12
up
up/active
178
==============================================================================
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
==============================================================================
=
Slot
Provisioned Type
Admin Operational
Comments
State State
-----------------------------------------------------------------------------1
imm1-100gb-cfp
up
up
2
imm12-10gb-sf+
up
up
3
imm5-10gb-xfp
up
up
4
(not provisioned)
up
unprovisioned
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
sfm3-12
up
synching/standby
B
sfm3-12
up
up/active
==============================================================================
STEP 11
(Major ISSU) ISSU Completion

Monitor the node to ensure that it returns to normal operation. All IOMs/IMMs 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 back up, and the standby CPM synchronized
(up).
==============================================================================
Card Summary
==============================================================================
Slot
Provisioned Type
Admin Operational
Comments
State State
-----------------------------------------------------------------------------1
imm1-100gb-cfp
up
up
2
imm12-10gb-sf+
up
up
3
imm5-10gb-xfp
up
up
4
(not provisioned)
up
unprovisioned
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
sfm3-12
up
up/standby
B
sfm3-12
up
up/active
==============================================================================
179
*B:Dut-A# show redundancy synchronization

==============================================================================
Synchronization Information
==============================================================================
Standby Status
: standby ready
Last Standby Failure
: N/A
Standby Up Time
: 2012/05/30 16:05:03
Standby Version
: TiMOS-C-11.0.B1-106 cpm/hops ALCATEL SR 7750
Copyright (c) 2000-2012 Alcatel-Lucent.
All rights reserved. All use subject to
applicable license agreements.
Built on Mon May 28 18:44:43 PDT 2012 by
builder in /rel11.0/b1/B1-106/panos/main
Failover Time
: 05/30/2012 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 IOMs and IMMs 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.
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.
STEP 12
(Major ISSU) Optional Post ISSU Actions

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).
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 (i.e., admin reboot upgrade).
On routers with non-redundant CPMs or CFMs
Each software release includes a BOOT Loader (boot.ldr). The BOOT Loader performs two
functions:
1.
180
Initiates the loading of the SR OS image based on the Boot Options File (bof.cfg) settings
2.
Reprograms the boot ROM and firmware code on the CPM or CFM and IOM/IMM/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/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 programming is required.
Note:
An admin reboot upgrade is required for all 7450 ESS-6/6v chassis running Release 6.1.R2
or earlier.
Note:
CONSOLE device 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.
Note:
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.
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.
181
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:\11.0.R20. 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.
Note:
If isa-aa.tim file was present in the image path the last time the node booted and an admin
save detail was performed, the configuration will fail to load completely if the isa-aa.tim file
is missing in the new image path.
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. Releases
prior to Release 11.0.R1 do not know about 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.
182
Known Limitations
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, 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.
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 configuration is saved in a
format that is fully compatible with the newly running release.
Known Limitations
Following are the known limitations for SR OS Release 11.0.R20.
Multi-Chassis
Synchronization
MCS synchronization of MLD snooping is not supported. The related command is not
blocked for backwards compatibility reasons but has no effect on the system if configured.
AUX Port
The AUX serial port on the SF/CPM or CFM is not supported in software. SR OS does not
provide a means of configuring the device.
IGMP Reporter
IGMP reporter has the following limitations:
EPIPE/VPLS
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
The following are not supported when Epipe or VPLS services are configured with a QinQ
PW (which is enabled using the parameter force-qinq-vc-forwarding) [181110]:
-
Multi-segment PW
BGP VPWS routes are accepted only over an iBGP session
Routed, Etree or PBB VPLS services
183
Known Limitations
L2PT termination on the QinQ PW
IGMP/MLD/PIM snooping within the VPLS service
Services configured with subscriber management using QinQ PWs.
ETH-CFM MIPs and MEPs are not supported on dynamically signaled BGP QinQ
PWs
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.
NETCONF
The following NETCONF protocol operations are not supported: <copy-config>, <deleteconfig>, <lock>, <unlock>.
Base capability 1.0 is supported.
The NETCONF interface does not support the equivalent of the CLI admin commands.
The NETCONF interface does not support the characters: <, , and &. These will
generate an error: Error in interpreting the NETCONF RPC
The filter match command is ignored.
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 NETCONF interface will not support ranges for any command.
Although the data plane interruption during a Soft Reset is minimized, there is a brief (nonzero) 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 7950 XRS line cards when using the default protocol
timers:
Soft Reset
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.
184
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.
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
Known Limitations
(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.
ISSU
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.
The architecture of some IMM cards prevents the support for the hard-reset-unsupportedmdas 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-resetunsupported-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+, imm340gb-qsfp, imm-1pac-fp3 and imm-2pac-fp3. [158482]
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. Refer to the Soft Reset sub-section of
the Known Limitations in the Release Notes for the source/starting release.
New firmware is required on certain MDAs in order to enable the new IEEE 1588 portbased timestamping feature introduced in Release 10.0.R11 and Release 11.0.R1. The
operator must hard reset (clear) the MDAs after a Major ISSU if Major ISSU is used to
upgrade SR OS from a release before 10.0.R11 to any 11.0 Release 11.0.R4 onwards (since
the MDA firmware is not automatically upgraded during a Soft Reset unless it is a
mandatory firmware update) in order to use the timestamping feature.
Switch fabric parameters have been tuned on all imm-2pac-fp3- and imm-1pac-fp3-based
IMMs in Release 11.0.R7, resulting in a mandatory hard reset during an ISSU. A Deferred
MDA Reset is not supported for these cases. A hard reset must be performed on these cards
during ISSU if the starting release is prior to Release 11.0.R7 and the target release is
Release 11.0.R7 or later. [166686]
A mandatory firmware upgrade on an MDA/IMM will cause a hard reset (instead of being
able to Soft Reset). A Deferred MDA Reset is not supported for these cases. A hard reset
must be performed during ISSU if the starting release is earlier than a mandatory firmware
upgrade and the target release is equal to or later than the firmware upgrade. Mandatory
firmware upgrades apply to the following cards and releases:
-
10.0.R11 and 11.0.R3: imm1-100gb-cfp and imm12-10gb-sf+ [132450, 134432]
10.0.R15 and 11.0.R7: imm-2pac-fp3/p1-100g-cfp/p1-100g-cfp, imm-2pac-fp3/p1010g-sfp/p1-100g-cfp, imm-2pac-fp3/p10-10g-sfp/p10-10g-sfp, imm-2pac-fp3 /p610g-sfp/p6-10g-sfp, imm-1pac-fp3 /p1-100g-cfp [157212, 157214]
10.0.R15 and 11.0.R7: imm3-40gb-qsfp [161786]
11.0.R6: x40-10g-sfp (WAN-PHY support introduction)
11.0.R10: m10-1gb-hs-sfp-b [177898]
11.0.R12: imm-1pac-fp3, imm-2pac-fp3, xcm-20, and xcm-16. Note that CLI

messages during the ISSU may incorrectly report that these cards can be Soft Reset.
[181115, 191100]
185
Known Limitations
Limitations specific to ISSU across minor releases (Minor ISSU) are as follows:
-
Minor ISSU is supported on platforms with redundant CPMs or CFMs. Minor ISSU
support is not available on the 7710 SR-c4, 7750 SR-1, 7750 SR-c4 or 7450 ESS-1.
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).
Performing a Minor ISSU from Release 11.0.R11 or earlier to a target release of

11.0.R12 and later requires a mandatory firmware upgrade of the SFM cards, which
results in traffic and protocol impact of up to a minute after the CPM switchover to
the new release. If the firmware is upgraded, the following log event is generated for
each SFM card: MAJOR: CHASSIS #2032 Base Fabric 8 "Class Fabric Module :
firmware upgraded. [184793]
Limitations specific to ISSU across major releases (Major ISSU) are as follows:
-
Major ISSU is supported on platforms with redundant CPMs. Major ISSU support is
not available on the 7710 SR-c4/c12, 7750 SR-1, 7750 SR-c4/c12 or 7450 ESS-1.
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 10.0.Rx -> 11.0.Ry where:
x and y are >= 4
The release date of 11.0.Ry is at least 90 days later than the release date of
10.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/CPM1 or SF/CPM2 cards.
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]
186
An admin reboot upgrade is required during the upgrade process to SR OS Release

9.0.R23, 10.0.R13, 11.0.R4 or later on all 7450 ESS-6/6v chassis and all 7750 SR and 7450
ESS chassis with SF/CPM1. ISSU cannot be used for this upgrade.
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.
VSM-CCA
The rates in a network-policy applied to a VSM-CCA or VSM-CCA-XP MDA are based

on 20 Gbps rather than 10 Gbps. 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 Gbps 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]
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]
Known Limitations
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.
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]
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.

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.

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
configure>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, m4atmoc12/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
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
FlowSpec
187
Known Limitations
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:
APS
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]
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 (e.g., m2-10gb-xp-xfp).
The imm1-oc768-tun card does not support APS.
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/7450 ESS platforms (not on 7710 SR) and with all IOM
types.
A mirror/LI destination SAP cannot be on an APS protected port.
Restrictions specific to SC-APS:
188
Bundles are not supported on ports (or contain ports) that are protected with unidirectional 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).
Known Limitations
ASAP MDA
Limitations
ATM MDAs
Access Mode Only
Ports with Frame Relay (FR) or Cisco HDLC encapsulation cannot be protected with
MC-APS.
Only bi-directional mode is supported with MC-APS. 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]
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.
The ATM interfaces on non-ASAP MDAs in the table below only support the customerfacing access mode.
Alcatel-Lucent
Part #
Description
3HE00074AA
3HE00071AA
3HE05944AA
3HE05945AA
For more information on the ASAP MDA, see ASAP MDA Limitations on page 189.
ATM and IS-IS
ATM Traffic
Management
Limitations
IS-IS is not supported on IES and VPRN interfaces with ATM PVC SAPs in this software
release.
The following only applies to the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs and do not
apply to the ASAP MDAs.
In the context of multiple services using an ATM MDA, the following two criteria must be met
in order to satisfy the QoS guarantees:
-
VC fairness
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 2 VCs with different ATM service categories, the due share will depend on the
priority of the service category and the configured rate, etc.)
189
Known Limitations
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]
ATM
Traffic/Statistics
Limitations
Class of Service
Fairness Affected
on Shaped VCs
The following limitations only apply to the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs
and do not apply to the ASAP MDAs:
OC-12/STM-4 latency increases when applying a new ingress SAP policy that adds more
queues. The latency increases from around 22.2 s to 24.8 s 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.
The following only applies to the OC-3c/STM-1c and OC-12c/STM-4c ATM MDAs, and do
not apply to the ASAP MDAs.
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 from 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 configured PIR of queue B.
[35224]
Shared Queuing
QoS
In a SAP Ingress QoS Policy with shared queuing, high-priority packets dropped will be
counted in the low-priority drops in the SAP ingress service queue statistics. [32335]
Frame Relay
If several MLFR links are removed rapidly from a bundle, one of the links may be deleted
before it has a chance to send out 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]
HW/Platform
The OES ports on the CCM-X20 are not supported (reserved for future use).
The Sync-E/1588 port on the CCM-X20 is not supported (reserved for future use).
190
Known Limitations
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).
The Optical Backplane Extension QSFP Ports on the CPM-X20 are not supported
(reserved for future use).
The CXP ports on the SFM-X20 and SFM-X20-B are 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 shutdown 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 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 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 or
7710 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 oddeven 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 holdtimer. [91563]
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]
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
191
Known Limitations
number of multicast capable paths is different between these card types; these
configurations must not be used. [118443]
RADIUS
192
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.
100G or 200G FP3-based Multicore-CPU IMMs cannot be used in a chassis equipped with
SF/CPM1, SF/CPM2, or SF/CPM3. Only SF/CPM4s are supported with these IMMs.
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 (i.e.,
configure 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.
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]
Known Limitations
Accounting
TACACS+
Configuring a fallback-action under configure subscriber-mgmt authentication-policy to

accept should not be combined with managed SAPs. Instead, it is recommended to set
fallback-action to user-db name and to configure a default host to catch all entries and to
provide default values for managed-SAP parameters.
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

policy minimum-collection interval must be 15 minutes. The total number of SAPs that use
the new accounting record type must not exceed 2048. [142879]
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 define if the user has just console or FTP
access, but a default template is supported for all TACACS+ authenticated users.
If TACACS+ is first in the authentication order and the TACACS+ server is NOT reachable, authorization for console access for the user is checked against the users 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 box.
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, 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 profile 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]
There is currently no show command to show the current values of the password hash
settings. [32747]
The firmware limits ICMP packet to be generated at the rate of 100 packets/sec. However,
when configuring an interface in the CLI, the user is allowed to configure ICMP packets to
be generated at rates up to up to 1000 packets/sec. [46767]
The system does not prevent the user from using the same IP address of its BGP peer on
one of its router interfaces. [57198]
Non-printable 7-bit ASCII characters (for example, French letters with accents) are not
allowed inside the various description fields. These characters were accepted for some
description fields prior to Release 8.0. When upgrading to Release 8.0.R1 or later, the user
must ensure that the configuration file does not contain any non-printable 7-bit ASCII
193
Known Limitations
characters that might have been in any description field prior to Release 9.0.
Configurations that do not comply may result in failed config exec in CLI and/or during
system bootup. [93998]
System
194
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 configure system rollback rollback-location does not support a TFTP location for the
file-url parameter (note that an FTP location is supported).
Although the http-download CLI command is referenced in the Systems Basics Guide, it
is not currently supported.
The no debug command does not remove the debug mirror information. [115892]
Candidate commands (e.g., 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).
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]
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-12/12e or 7450 ESS-12 or 7750 SR-7 or 7450
ESS-7, an erroneous fan high temperature alarm is generated that is cleared when the fan
is replaced. [36112]
Remapping of control plane traffic from a default CPM queue to a different queue is not
supported on the 7750 SR-c4/c12 or 7710 SR. [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]
Soft Reset outage times may be higher than expected if one or more IOMs are soft-reset
while the standby CPM is rebooting. [73285]
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.
Known Limitations
The per source IP rate limiting function of cpu-protection (ip-src-monitoring) only applies
to DHCP packets and is supported for packets arriving on IES sub-if grp-if SAPs only.
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 queueing 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]
On iom2-20g network interfaces, pings of IPv6 addresses initiated from an SR OS node are
not counted in the egress counters. [192990]
The following differences are observable in iom2-20g and FP2- and higher-based line cards
interface counters:
-
When using the command (no) enable-ingress-stats, 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 stats (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
stats) but not on iom2-20g (SAP stats). SAP stats 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 higherbased line cards, egress discards are always increased, even when a do-notfragment message is not sent. On iom2-20g, egress discards are never increased,
even when a do-not-fragment message is sent. [193662]
IPsec
In a multi-active tunnel group setup, ICMP pings to the tunnels local address may fail.
[140341]
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.
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]
IP/RTM
The offramp- and mgmt-vprn interface should be on IOM3-XP or higher. [126826]
195
Known Limitations
ATM
VSM-CCA
ASAP
196
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]
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]
Refer to the SONET/SDH section in Known Limitations 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]
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]
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]
In exceptional cases, especially in a fully loaded node, where the occurrence of a HighAvailability 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]
Known Limitations
DS3 configuration with m23 framing on the channelized ASAP MDA may detect false
AIS. This may cause the DS3 to bounce occasionally. [74671]
ESM Host Lockout
Lockout is not supported for LNS.
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 (e.g., 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 IOM3XP/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]
When lag-link-hashing or lag-link-mapping-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-link-hashing or lag-link-mapping-profile is used for a given SAP or network

interface egress traffic and BFD is enabled on that interface, BFD packets remain roundrobin 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.
Due to a large number of service combinations, per-link-hashing and LAG link-mapprofiles configuration with LAG and unsupported services are not blocked. The supported
services for these features are explicitly listed in the New Features and Enhancements
sections of this document.
Pulling out the active CPM/CFM can, in rare cases, result in LACP to signal to adjacent
nodes that ports are going down. When an active CPM/CFM has to be removed for
replacement, it should first be switched over to become the standby CPM/CFM and can
then be pulled out safely. [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]
197
Known Limitations
MLPPP
Management
Release 11.0.R1 only supports LAG link map profile for IES SAPs when there are no other
services configured on the LAG. It also supports LAG link map profile for Epipe SAPs
with an empty profile with other services on the LAG using per-flow hashing (refer to
the SR OS Interface Guide for more details).
If several PPP member links in a MLPPP bundle are removed or shut down at the channelgroup 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 keepalives 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]
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]
Collision events detected on a CPM or CFM management Ethernet port are reported as
CRC/Alignment errors. [30205]
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]
The SSHv2 implementation does not support the RC5 cryptographic algorithm. [47122]
After 497 days, system up-time will wrap around due to the standard RFC 1213 MIB-II 32bit limit. [51129]
The following considerations apply to the IF-MIB enhancements introduced in Release

11.0.R5:
-
198
The following counters are not incremented:

-
ifInErrors/ifInUnknownProtos/ifOutErrors
Multicast/Broadcast/NUcast counters.
The enable-ingress-stats option must be enabled in CLI in order to increment the

ingress IF-MIB counters. Ingress IF-MIB counters are updated even if a packet is
discarded on an incoming interface. 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 interfaces.
The following commonalities exist between IES/VPRN and Base Router interface
counters:
-
Discard packets that need fragmentation but the DF bit is set: ifOutDiscards is
updated
Discarded Broadcast-traffic: InDiscard is not updated
Known Limitations
Data traffic is not reflected in the counters for a tunnel interface. Only control
traffic (e.g., LDP, RSVP, OSPF, IS-IS, etc.) 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.
Different behaviors are observed for ifOutDiscards between IPv4 and IPv6 on the
7950 XRS/7750 SR and 7710 SR if the DF bit is set on a ping with too large of a
frame size. The counter is incremented for both IPv4 and IPv6 packets on the 7710
SR, but it is incremented for IPv4 only on 7950 XRS/7750 SR. [146878]
Routing
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]
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]
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 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]
A router with more than one point-to-point adjacency 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. [91520]
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 routes next-hop information.
199
Known Limitations
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]
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 done when uRPF is enabled for IPv4 and
IPv6; otherwise, the counters may not be reset to zero (0). [174961]
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 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 sync with a DHCP server using
failover-per-server. [169222]
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]
TCP
Authentication
Extension
It is not possible to delete an authentication keychain if that keychain was recently removed
from a BGP neighbor while BGP was operationally down. BGP has to become
operationally active before the keychain can be deleted. [57277]
Filter Policies
IP filters with a default-action of discard will not discard 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]
A single filter policy entry does not support multiple match lists used for match criteria.
When a match list is used in a filter policy entry, the resulting filter policy entry is allowed
to take up to a tenth of HW resources for this filter policy. [142472]
DHCP
RIP
200
Known Limitations
IPv6
L2TPv3 SDP
If any uncommitted configuration changes exist (e.g., configure router policy-options

begin without the final commit) when a force-switchover command is issued to initiate
Major ISSU, then the uncommitted configuration changes will be lost. Uncommitted
configuration changes are not written to the configuration file during an admin save
operation. [159876]
Filter policy Time-of-day (ToD) functionality (configure>filter>>entry [time-range timerange-name] is not supported with new filter policy functionality released in Release
11.0.R4.
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 not match fields in the outer IP header but
will match fields of the inner IP header instead. [189799]
When debug router ip packet is enabled, packets received on a 6over4 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
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 <etc>
Pseudowire shaping
Ingress/egress QoS functionality
Pseudowire switching
Active/standby pseudowire services and inter-chassis backup
PBB
Hash-label
201
Known Limitations
PW Status signaling
Operators expecting to deploy this feature set should contact their Alcatel-Lucent engineering support teams.
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. It is recommended
not to depend 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 computed 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 configured, 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]
OSPF
202
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. Hence, a P2P configuration is recommended. [138279]
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]
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 them. [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]
Known Limitations
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]
OSPF PE-CE
Traffic engineering is not supported in OSPF PE-CE 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]
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]
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 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 on the peer/group level, a set/reset of local-AS on 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.
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.
It will clear the BGP routes before entering the helper mode. The proper way to trigger
Graceful Restart 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]
203
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]
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 shutdown. [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 and 7710 SR 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.
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 disabled. [60261]
204
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]
Known Limitations
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]
LDP
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.
MPLS-TP is not supported on 7750 SR-1, 7450 ESS-1, 7950 XRS and 7710 SR.
SVC-Ping and SDP-ping are not supported on MPLS-TP LSPs and PWs.
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.
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 "combined-ldp-lsp-egress" are configured in that policy. [84406]
205
Known Limitations
IP Multicast
When enabling or disabling the ldp-shortcut option in the global routing context, any
indirect LDP static-route will flap and its age will be reset. [85366]
When configuring the peer-parameters, the peer address represents the peer LSR-ID or the
peer transport address, depending on the configured capability. For instance, the peer
address is the transport address for the MD5 capability while it is the peer LSR-ID when
the capability is LDP Downstream on Demand (DoD), the peer import and export policies,
or the TTL security. [91436]
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]
When performing Major ISSU to Release 11.0 from a prior release, an LDP session to a
peer LSR will not bounce and as such, the new LDP overload protection capability TLV
will not be signaled. If LDP runs out of data path or CPM resources, it will use the base
graceful handling capability instead of the enhanced graceful handling capability until such
a time the LDP session bounces. [163266]
The Router Alert IP option is not included in mtrace queries that are unicast to the last-hop
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]
Cisco routers that incorrectly send mtrace queries to the group multicast address rather than
the ALL-ROUTERS.MCAST.NET address (as defined by the IETF draft) will be
discarded. Additionally, some Cisco routers do not fill in the oif field in the response
block, and some do not accept an mtrace query that comes in on the oif interface. A
workaround in this last case is to use the RPF as the destination address for the query.
[39070]
(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 reenabled. 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 option bundle 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:
206
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.
Known Limitations
PIM
QoS
Some multicast limits (e.g., the number of OIFs per IIF per line card) are not enforced by
the system; thus, it is recommended that operators verify with Alcatel-Lucent support
teams that planned deployment limits are supported.
RPF Vector must be enabled on every router for Rosen 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]
Enhanced multicast load-balancing (config>system>mc-enh-load-balancing) is mutually

exclusive with PIM LAG usage optimization (config>router>pim>lag-usageoptimization), since CPM-based load-balancing cannot mimic data-path-based loadbalancing 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]
There is no CLI show command to see the SSM groups configured on PIM. The only way
to see those SSM group is to use info in the config menu. [33746]
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]
It is recommended to use 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]
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
207
Known Limitations
which the line card will allocate multicast queues and the line card and CPM will be in
sync. [42469]
208
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 nonnamed-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 classagg-weight and frame size, such that frame_size/class-agg-weight results in a value lower
than 64 bytes. Hardware will round up the value resulting from frame_size/class-aggweight to be at least 64 bytes as the fairness algorithm expects at least 64 byte frames. A
few examples of such combinations are: 200-byte frames and weight 8, 100-byte frames
and weight 4, 70-byte and 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 (i.e., 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 offeredcombined 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 (i.e., IOM3-XP) or that is inserted in a 7750 SR-c4/c12 or 7710 SR-
Known Limitations
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]
PBR/TCS
Services General
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 can have different adapt-qos
modes, anything at the port level (such as 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. [183846]
At 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. At ingress, IPv6 routed packets
ignore MAC-based QoS classification criteria, while switched packets ignore IPv6-based
ACL match criteria. At egress, IPv6 QoS-based classification criteria are ignored when
MAC-based ACLs are configured. [208461]
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 CLI does not display an error when the user attempts to apply a filter log and a mirrorsource 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, it is recommended that
the redundant spoke-SDPs be operated in non-revertive mode. [67252]
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
209
Known Limitations
workaround is to set the ARP cache timeout to a lower value on the Ethernet CE router.
[78805]
Subscriber
Management
210
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 redirect-policy with a ping test in the context of a VPRN may not work as expected. The
system may incorrectly send ICMP packets to the base instance instead of the VPRN
instance. [83771]
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.
Ipipe spoke-SDP termination on IES/VPRN is not supported over an iom-20g-b. Traffic

loss may be observed if an Ipipe spoke-SDP bound to an IES/VPRN interface is routed
over an iom-20g-b. [111487]
Configuration of IPv6 is not supported on Ipipe spoke-SDP terminations in an IES or

VPRN service context. [128543]
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]
When force-vlan-vc-forwarding is configured in a PW-template being used by BGP-AD

and when provider-tunnel is enabled and its owner is bgp-ad, the root node does not
preserve the ingress tag. [218480]
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.
Dynamic subscribers learned (via DHCP) while sub-sla-mgmt is shut down will continue
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]
An up-front DHCP relay server in combination with Wholesale/Retail configuration is not

supported. [72138]
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
Known Limitations
(DHCP/static/ARP) subscribers. PPPoE hosts can use these addresses starting from
Release 9.0.R3 with the support for PPPoE unnumbered interfaces. [78233]
An IPv6 subscriber can be mirrored/LId 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).
When a CoA request is sent for changing the subscriber-ID of a subscriber host in a dualstack 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 in
this release:
-
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
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 stats require
the reconciliation of the policer and queue stats. It is, therefore, recommended to wait 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, igmpsnooping 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 maximum number of hosts within the subscriber or the sla-profile instance that can be
affected by a single CoA is 32.
211
Known Limitations
212
The following restrictions for DHCPv4 over PPPoE apply:

-
The DHCPv4 client must be connected via a CPE that acts as a DHCP relay.
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]
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]
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 server can only be used in combination with a DHCPv6 relay
on a group-interface with Enhanced Subscriber Management (ESM) enabled. Using an SR
OS DHCPv6 server as a standalone server with DHCPv6 relay on a regular interface is not
supported. [149028]
Synchronization of subscriber IGMP 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 state will be synchronized to the standby node but will
fail installation with the reason IGMP interface not found. [155540]
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, it is recommended to
enforce at least the default lease-time of one hour by configuring the pool min-leasetime. [157485]
The following limitations apply for a PW SAP for IES/VPRN services:

-
PW SAPs require IOM3-XP and are supported with the HS-MDAv2
PW SAPs are only supported on Layer-3 service interfaces (ie., IES and VPRN), in
addition to the group interfaces supported in Release 11.0
Only Ethernet PWs are supported
Ethernet CFM is not supported on the Ethernet PW or PW SAP
No support for BGP-3107-based transport LSP
No support for mixed SDP types
No support for PW Control Word
No support for hash-labels
mac-sid-ip anti-spoofing for PPPoE on the group-interface cannot be used in combination

with L2TP LAC.
Once set, the following attributes cannot be changed for a Web Portal Protocol (WPP) host:
-
Framed-IP-Address
Alc-IPv6-Address
Known Limitations
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
VLL Spoke
Switching
If the Control Word is modified on a TPE device in a pseudowire switched environment

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]
When a CPM or CFM switchover occurs during STP convergence, a temporary traffic loop
or a few seconds of traffic loss may occur. [78202, 77948]
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.
213
Known Limitations
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]
IPsec
IPsec-ISA cards (3HE03080AA) are no longer supported starting with Release 8.0.R5.
Instead, they have been replaced with MS-ISA cards (3HE04922AA).
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 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 use of auto-bind and spoke-SDP within a VPRN is mutually exclusive. [21529]
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]
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 -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.
VPRN/2547
214
Known Limitations
If a VPRN is configured to use autobind 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 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 GRE command is applied. [167012]
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]
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]
MoFRR
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.
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. [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]
Simultaneous Filter Logging and Service Mirroring on egress is not supported. When
simultaneously performing filter logging and service mirroring at egress, the service
mirroring operation takes precedence over the filter logging operation. This behavior was
VRRP/SRRP
Mirroring / Lawful
Intercept
215
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 or 7710 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.
The special purpose LI filters (configured under config>li>li-filter) are supported for MAC
LI filters only.
LI/Mirroring at the LAC for subscribers using MLPPPoX access is not supported. LI at the
LNS is recommended instead.
LI at the LNS for MLPPPoX (oE/oA/oEoA) subscribers is only supported with a mirrordest 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 Intercept criteria (e.g., configure li li-source x nat in CLI) cannot be
configured/triggered/used via RADIUS.
Spanning Tree
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.
Ingress Multicast
Path Management
The show mcast-management channel command does not show counts of the
replications on the ancillary path. [65824]
Multicast traffic may be affected for ten seconds on a soft reset of the ingress card. [76417]
Ingress multicast traffic through a queue with multipoint-shared queueing 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]
AA-ISA cards (3HE03384AA, 3HE03385AA) are no longer supported starting with

Release 8.0.R1. Instead, they have been replaced with MS-ISA cards (3HE04922AA and
3HE05142AA).
Application
Assurance
216
Known Limitations
Video
When deleting an application or an application group, statistics for the current accounting
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 appgroup assignment is changed in an application, the flow count for the associated protocol is
doubled.
All subscribers being serviced by an MS-ISA card must be removed from the MS-ISA
prior to removing the card from an application-assurance-group. [77394]
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 retailers 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 1Gbps 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]
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 between 7750 SR-c12 and non-7750 SR-c12 chassis types.
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]
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 or
from a PBB service.
The Video ISA card (3HE04287AA) is no longer supported starting with Release 8.0.R1.
Instead, it has been replaced by MS-ISA cards (3HE04922AA and 3HE05142AA).
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. It is recommended to
configure PIM SSM to avoid the issue.
This may result in a slow FCC or unrepaired packet loss. The show video channel command 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 incre-
217
Known Limitations
ments, the workaround is to use the command clear router pim database to get out of the
state. [82353]
PPPoE
BFD
218
In normal operating conditions, the RTP-sequence numbers for a channel are increasing
monotonically. An equipment failure upstream of the video-interface (i.e., rewrapper-issue,
intentional reset of sequence numbers,etc.) 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]
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-subscribermanagement 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]
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]
PPPoE, L2TP-LAC and L2TP-LNS are not supported on a 7450 ESS-6 or ESS-6v in
mixed-mode. [117721]
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]
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]
BFD sessions associated with LAG groups, spoke-SDPs, and multi-hop BGP and VSMs on
a 7750 SR-1 or 7450 ESS-1 or 7710 SR are limited to a minimum interval of 300
milliseconds. If a lower interval is configured, a log message will be raised and the
associated BFD session will not be established.
Known Limitations
NAT
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 or RSVP shortcut routes. [135994]
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 with chassis mode D. In chassis mode C and
lower, multi-hop BFD will only work with UDP port 3784. [185612]
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 payload 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 connect 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 others IPv4 outside
addresses and no client will be able to start the connection.
RTSP Connection information in an RTSP message describe 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>nat-acct-plcy>radius-acct-server source-address-range" required depends

on how many MS-ISAs maximum are configured in a NAT-group, including the MS-ISAs
that were removed before without having the node rebooted. For every MS-ISA, a unique
source address is used and may fall out of the source-address-range in case the sourceaddress-range is not configured sufficiently. [138967]
Dual-homing and Lawful Intercept in combination with deterministic NAT are not
supported in Release 11.0.R1. [151001]
219
Known Limitations
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
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.
PBR is not supported in conjunction with L2-Aware NAT. In cases where PBR is enabled
for L2-Aware NAT, traffic will be NATd but PBR will not be executed.
L2-Aware NAT is not supported on the Retail service in a Wholesale/Retail Routed-CO

model. Large-scale NAT can be used instead.
NTP
Configuration of PTP as an NTP server will be lost when an High-Availability switchover

occurs. This will cause NTP to become free-running if there is no other NTP source
configured. If there is another valid NTP source configured, it will be acquired, but the
system clock accuracy will be less than the accuracy obtained from the PTP source. The
recovery solution is to reconfigure PTP as an NTP server after a High-Availability
switchover occurs. In Release 11.0.R5, it is recommended that PTP as an NTP server be
used for lab trials rather than deployment. [166754]
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]
The number of active TMS ECMP routes is always displayed as one (1) in the output of the
command show router route table summary even if the actual count is higher than one.
[120740]
The offramp- and mgmt-VPRN interface must be on IOM3-XP or higher. [126826]
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]
OAM
220
Known Limitations
OAM-vprn ping and traceroute for VPRN in a hub and spoke topology using hairpin
routing does 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.
OAM-vprn ping and traceroute does not work in a hub and spoke network topology with
the 7750 SR or 7450 ESS in mixed mode, 7710 SR or 7950 XRS as the Customer Edge
(CE) hub. As a workaround, the 7750 SR or 7450 ESS in mixed mode, 7710 SR 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.
For Service Assurance Agent tests where the 7750 SR-1 or 7450 ESS-1 is the terminating
node, the accuracy of the tests are affected by the precision of the internal clock and have a
margin of error of up to 10 ms. For trace tests with the 7750 SR-1 or 7450 ESS-1 as an
intermediate node, the 10 ms margin of error also applies. The accuracy of the Service
Assurance Agent tests on the 7750 SR-7/12/12e/c12 and 7450 ESS-6/6v/7/12 as
terminating or intermediate nodes are typically on the order of 1 ms.
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]
LDP treetrace and LSP trace with the path-destination option enabled are not supported on
an LDP FEC that is tunneled over an RSVP LSP (LDP-over-RSVP tunnel). [73650]
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 and LSP trace with the path-destination option are not supported on an LDP
FEC that is stitched to a BGP labeled route. [105364]
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]
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 lsptrace 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]
221
Resolved Issues
The following OAM tools were 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.
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]
p2mp-lsp-ping is not supported with an RSVP P2MP LSP or an mLDP FEC used as an IPMSI in VPLS context [154657].
p2mp-lsp-trace is not supported with an RSVP P2MP LSP used as an I-PMSI in VPLS
context. [154659]
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]
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]
Resolved Issues
Note:
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.
Resolved in 11.0.R20
Following are specific technical issues that have been resolved in Release 11.0.R20 of SR OS
since Release 11.0.R19.
HW/Platform
222
Sending a very specific combination of multicast and unicast high-bandwidth traffic

streams with a traffic generator over an FP3-based line card could, in very rare cases, have
resulted in a lockup of the forwarding plane on that line card. This issue has been resolved.
[198631-MA]
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]
Resolved Issues
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]
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]
RADIUS
RADIUS proxy cache population through track-mobility is now limited to RADIUS

proxy cache scale. [205963-MA]
System
A configuration of cron>schedule>action that pointed to both a long action-name and a

long action-owner could have caused truncation and corrupted names and action
associations. The error occurred when the total length of the action-name and actionowner configured in the cron>schedule>action command exceeded 45 characters. This
issue has been resolved. [200973-MI]
When a Compact Flash was in a failed state, subsequent attempts to read or write to it could
have affected SNMP and resulted in slower telnet access. This issue has been resolved.
[205799-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
been resolved. [211910-MI]
CPM-originated control packets that contained data errors were incorrectly forwarded to
the MS-ISA card control plane. This could have resulted in missing information in show
commands that retrieve information from the MS-ISA MDA and the following alarm:
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 issue has been resolved. [214054-MI]
When removing an mc-lag configuration, it was possible for the port to remain down
with the reason lagMemberPortStandby. This occurred if MC-LAG was not shut down
before attempting to remove the mc-lag configuration. To avoid this issue, 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 resolved. [213636-MI]
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]
A prefix-list linked to a static route, followed by an implicit or explicit policy abort, could
have caused a node reboot after the next creation of the same prefix-list when followed
with a commit. This issue has been resolved. [208340-MA]
The ARP table of the management router instance did not get updated upon receiving a
gratuitous ARP. This issue has been resolved. [210882-MI]
MC-LAG
Routing
223
Resolved Issues
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]
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. In previous releases, the message drops caused a rare interoperability
issue with a third-party router which expected a Neighbor Advertisement in response to
such a Neighbor Solicitation. [205524-MI]
IS-IS
IS-IS adjacencies will no longer continuously bounce if the underlying transmission

network connecting the IS-IS nodes has issues such as a Layer-2 loop. [205800-MA]
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]
In a scaled configuration where a large number of prefixes were being leaked from L2 to
L1, it was possible that after a High-Availability switchover the L1 LSPs would get
generated without the up/down bit set for some of the leaked prefixes. This issue has been
resolved. [219213-MA]
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, resulting in the lease-populate limit to be reached sooner
than expected. This issue has been resolved. [195537-MA]
In very rare cases, the active CPM/CFM might have reset if the forwarding of a DHCPsnooped packet failed. This issue has been resolved. [212822-MI]
Receiving a DHCP discover message while WPP host is logged in will trigger reauthentication, which no longer will incorrectly change the WPP user name to the MAC
address of the host and use that new user name in subsequent Accounting messages.
[210763-MI]
Receiving an OSPF update message with an external LSA from an OSPF neighbor would
have resulted in the aggregate summary LSA for that same prefix to be withdrawn. This
issue has been resolved. [206073-MA]
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 may have taken longer than expected to converge. This issue has been resolved.
[210380-MI]
The following display commands consumed memory which was never released:
DHCP
OSPF
show router router-name ospf ospf-instance opaque-database when followed by the

parameters adv-router router-id or ls-id
show router ospf capabilities
A CPM/CFM switchover was required to free up the memory if these commands were executed many times and consumed a substantial amount of memory. This issue has been
224
Resolved Issues
After an interface was added in a new OSPF area and the compatible-rfc1583 option was
toggled, summary LSAs with routes that were an exact match to configured area ranges
were incorrectly withdrawn from the database of a different area that contained the lowest
intra-area (IA) route. This issue has been resolved. [211961-MA]
BGP
After a CPM or CFM failover, BGP graceful restart failed initially. It did start to function
after the neighbor session was flapped and capability messages were exchanged. This issue
was actually resolved in Release 11.0.R6. [85601-MA]
LDP
In rare cases after a node reboot, some LDP tunnels might not have been programmed
correctly on some line cards, resulting in blackholing for traffic routed into the affected
tunnels. This issue has been resolved. [208462-MA]
The graceful-restart capability information in the show router ldp session command
output could have been displayed incorrectly after a CPM/CFM High-Availability switchover. This was only a display issue and has been resolved in Release 11.0.R20. [212828MI]
mVPN
PIM groups are now correctly resolved when using a BGP confederation with P2MP
provider-tunnels. [191479-MA]
QoS
The WRED buffer allocation pool size could have been incorrectly calculated if bufferallocation configuration was done while the wred-queue-control was in a no
shutdown state. This issue has been resolved. [215517-MI]
Filter Policies
The configuration file no longer fails to execute when a LAG that is used in a mac-filter
is deleted. Instead, a minor CLI error will now be generated. This issue was actually
resolved in Release 11.0.R15. [187246-MI, 211930-MI]
Services General
When using an LDP-based SDP and LDP resolved multiple ECMP paths to the far-end
prefix of the SDP over RSVP LSPs for which the next-hops were reachable via different
line cards, CPM-/CFM-originated traffic (such as Routing Protocols, ICMP, or OAM) may
not have egressed out of the spoke-SDP for the following types of services: IES/VPRN
spoke-terminated interfaces, Pipe services, and Routed-VPLS services (Layer-3 control
traffic). This issue has been resolved. [201386-MA]
In rare cases, the standby CPM/CFM might have reset if an SNMP set operation created a
SAP in a VPLS which was operationally up, and then administratively shut down. The
reset could have happened 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]
The DS-Lite subscribers 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
Subscriber
Management
225
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. This issue has been resolved. [206105-MA]
VPLS
IPsec
226
In some cases when MLPPP was enabled on the LNS node and an MLPPP error occurred,
taking a Tech Support file would have caused the MS-ISA cards to reset. This issue is
present in Release 11.0.R19 only, and has now been resolved. [214015-MA]
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]
In certain scenarios where L2TP tunnel accounting was enabled, it was possible for some
closed L2TP tunnels to hang and not be removed from the system. If the number of the
hanging 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 has been
When using ssm-translate in a Routed-VPLS service, if a (*,G) join had been received in
the VPLS and translated to an (S,G) to be sent to the routed side of the service, the related
multicast stream would have been forwarded correctly; however, if the same (*,G) had
been later received on a SAP or mesh-/spoke-SDP on a different forwarding complex than
the initial join, then the multicast stream would not have flowed towards that new complex.
This issue has been resolved. [211398-MA]
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 policy that set the amount of secondary paths to a higher value
than the default of one (1). This issue has been resolved. [214451-MA]
Static routes pointing to static LAN-to-LAN tunnels configured with auto-establish

would have become inactive after the primary MS-ISA came back online after resetting, if
the tunnel group had a backup MS-ISA. To recover and re-activate the static routes, the
tunnel had to be re-established (for example, cleared with CLI). This issue has been
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 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
IP filters were not programmed on a tunnel SAP after a node reboot or after
administratively toggling the MS-ISA shutdown/no shutdown. This issue has been
An IPsec SA (phase-2) would not have been deleted immediately after a Dead Peer
Detection (DPD) timeout if the UDP source port of the ISAKMP messages sent by the
client had not been equal to 500 and NAT traversal had been disabled in the IKE policy.
The IPsec SA would eventually have been deleted when its lifetime expired. This issue has
Resolved Issues
The output of debug ipsec tunnel or debug ipsec gateway tunnel did not display
retransmitted IKE packets. This issue has been resolved. [216923-MI]
An accounting policy that collected video records to a file that was located on a nonexisting or non-functional compact flash would have caused a continuous increase of
memory consumption on the CPM. In time, this could have caused the memory on the
CPM to be depleted. Workarounds were to either point the accounting policy to a file which
was located on a functional compact flash or to shut down the policy. This issue has been
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]
NAT
Continuously creating NAT dynamic port-forwards with PCP while toggling the natgroup three or more times could have resulted in system instability. This issue has been
Application
Assurance
When an admin application-assurance upgrade command was performed on the

7750 SR-c4 and 7750 SR-c12 platforms, the ISSU state was not entered (as indicated by an
ISSU operational state on the show mda output), and the two-hour clear timer was not
started (the clear timer is applicable to the 7750 SR-c12 only). This issue has been
Partition-level protocol accounting statistics would not have collected statistics for new
protocols introduced as a result of an AA-only ISSU. Performing a shutdown and then a
no shutdown of protocol statistics on the affected partitions would have triggered the
collection of statistics for the new protocols. This issue has been resolved. [209626-MI]
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]
OAM
OAM lsp-ping and lsp-trace might 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 specified. This was only an issue with the OAM command and not with the actual data
traffic. The following error was seen: "Packet size too big." This issue has been resolved.
[216677-MI]
Video
227
Resolved Issues
HW/Platform
CLI
System
228
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 being raised. This issue has been resolved.
[200605-MI]
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]
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]
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 11.0.R19, 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 status LED of an unprovisioned SFM5 card would incorrectly show solid amber
instead of blinking green. This issue has been resolved. [207580-MI]
The output of show card detail may not always have displayed the source of detected
FCS errors. This issue has been resolved. [209479-MI]
Executing show router service-name ? on a 7750 SR-1 chassis could have caused a reset
of the node. This issue has been resolved. [203028-MA]
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.
This issue has been resolved. [204200-MI]
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 issue has been
If default log-id 100 was deleted and then recreated with default filter 1001, after a full
node reboot and loading the saved configuration file, filter 1001 would incorrectly no
longer have been 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]
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]
Resolved Issues
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. This issue has been resolved. [207854-MI]
In rare cases, the following false alarm was generated for Ethernet MDAs on which Sync-E
was not configured: CRITICAL: LOGGER #2002 Base 5:MDADRV:UNUSUAL_ERROR
Slot 5: bridgeCheckSonetClkChange: MDA 5/2: Both clock selects asserted. This issue
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).
MC-LAG
A High-Availability switchover on the standby MC-LAG (without LACP) peer may have
sometimes caused the standby ports to toggle operationally. This issue has been resolved.
[193578-MI]
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 solutions.
OSPF and IS-IS were both affected by this issue. This issue has been resolved.
[200750-MA]
Routing Policies
The combination of a long prefix-list name and IPv6 prefix may have been rejected by CLI.
The workaround was to modify the prefix-list name to a shorter one. This issue has been
DHCP
Removal of a DHCPv6 lease-state triggered by a lease timeout could have incorrectly

resulted in a subMgmtIpoe lost sync with peer event 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; hence,
this was a false alarm. This issue has been resolved. [198763-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 number of IS-IS Total Exp Routes for L1 and L2 seen in the output of show router
isis status may have been incorrect in certain scenarios. This could have had an impact on
the routes that were actually exported in IS-IS in case an export-limit was also
configured as the number of IS-IS Total Exp Routes displayed in CLI is used against the
configured export-limit value. This issue has been resolved. [180100-MI]
When an IS-IS instance was configured with multi-topology ipv6-multicast and a routenh-template configured with protection-type link was added to an IS-IS interface, after
229
Resolved Issues
a reboot of the active CPM/CFM, the calculated LFA would be correct but its metric would
not be. This issue has been resolved. [188681-MI]
OSPF
BGP
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
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 blocked if sham links were configured in the VPRN OSPF instance. This issue
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 certain scenarios where a local route exactly overlaps 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 advertised via an BGP export policy, both policy entries
from protocol direct and from protocol aggregate were required. This issue has been
Disabling BGP split-horizon (no split-horizon) in Release 10.0 at the neighbor level did
not carry over after Major ISSU to Release 11.0. BGP split-horizon would be enabled, even
when the running configuration showed that split-horizon was disabled. This issue has
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
has been resolved. [208134-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.
A workaround was to remove then 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-VPWS
230
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 sdpinclude/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
Resolved Issues
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
The output of the tools dump router ldp memory-usage CLI command could have
incorrectly contained negative values. This issue has been resolved. [138848-MI]
IP Multicast
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]
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]
QoS
Ingress IPv6 packets on an Epipe or VPLS SAP that had a MAC-based ACL filter applied
would not have been correctly classified based on DSCP criteria in the QoS policy. This
Services General
Subscriber-management-related persistency files may have been reformatted about once

per month on nodes that had their time synchronized via Simple Network Time Protocol
(SNTP). This was not an issue on nodes that use Network Time Protocol (NTP). This issue
Using the management routing instance to reach a Diameter peer may have resulted in an
active CPM/CFM reset. This issue has been resolved. [202962-MA]
Sending a RADIUS COA disconnect that was first executed on a PPP-DHCPv6 host for a
subscriber having multiple hosts incorrectly did 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]
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
Management
In rare cases, a PPP link, terminated in a 7750 SR LNS, that went down in an MLPPPoX
bundle with multiple links could have resulted in an LNS MS-ISA reset. This issue has
been resolved. [206761-MA]
IGMP
It was possible to configure R-VPLS on an interface which also had MLD configured,
although this is 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]
231
Resolved Issues
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. Counters for invalid version messages in the show router vrrp
statistics command output should instead have been increased. This issue has been
Video
A debug configuration for video services saved with the command admin debug-save
can now be successfully executed. [208650-MI]
WiFi Offload and

Aggregation
When a system interface IP address was not configured under a routing instance, an
unwanted GTP packet received by this instance would have incorrectly resulted in a critical
log error ...gtpPathDbNew: Failed get wlanGw src Addr No interface "system" found.
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 WLANGW 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
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]
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]
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 11.0.R19, it is no longer incorrectly allowed to change the active
IOM limit in a WLAN-GW group containing active subscriber cache entries for subscriberaware LSN NAT. [209701-MI]
WLAN-GW and
NAT
User-created SAPs that use internal MS-ISA ports are no longer allowed. Configuration via
CLI or SNMP is blocked, as well as via script execution. Note that if any of these SAPs
already exist when doing a Minor or Major ISSU, the ISSU will fail. [187888-MI]
Application
Assurance
Under unexpected Microsoft Lync traffic conditions, the MS-ISA may have raised a trace
event or rebooted. This issue has been resolved. [212346-MA]
Cflowd
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
NAT
232
Resolved Issues
BFD
On systems equipped with CPM5 cards, support for sub-second BFD timers on MPLS-TP
label-switched paths is now available. [204825-MA]
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
OAM
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 was no longer forwarding traffic. This issue has been resolved.
[202459-MI]
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 would have been declared again after this brief period of time. This issue has
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-pol-
233
Resolved Issues
icy on both FPs. The workaround is no longer necessary as 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]
234
HW/Platform
Release 11.0.R12 introduced a new mandatory firmware upgrade with various

improvements for the SFM cards on 7950 XRS platforms. This SFM firmware upgrade
results in traffic and protocol impact of up to a minute after the CPM switchover to Release
11.0.R12 or later during a Minor ISSU from Release 11.0.R11 or earlier. If the firmware is
upgraded, the following log event is generated for each SFM card: MAJOR: CHASSIS
#2032 Base Fabric 8 "Class Fabric Module : firmware upgraded. [184793-MA]
System
The file version check command could have failed on large files like support.tim on
nodes that have 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
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
Management
The IPv6 loopback address 0::1 is now correctly blocked in log snmp-trap-group traptarget configuration. [201542-MI]
BGP
After a lot of network churn, or some other condition that triggered a high number of BGPAD auto-generated SDP delete and recreate events, it was possible for the ID used for a
newly auto-generated SDP to become one (1) and any subsequent auto-generated SDPs to
fail creation, with the message: The system failed to create a dynamic bgp-l2vpn SDP
Bind in service x with SDP pw-template policy y for the following reason: Internal Error.
The state could be recovered by performing a High-Availability switchover or rebooting
the node. This issue has been resolved. [198010-MA]
Resolved Issues
IPv6
When creating an IPv6-only interface, an Interface interface-name is not operational

message might have appeared in the event logs even though the interface was up and
running. This issue has been resolved. [124576-MI]
Subscriber
Management
Optimizations have been implemented to handle more RADIUS Accounting Requests by a

node acting as RADIUS proxy. [194203-MI]
VPRN/2547
VPRN traffic arriving on a network interface over a GRE or MPLS tunnel will no longer be
dropped if the source address in the inner IP header is equal to the network or broadcast
address of the incoming network interface. [203893-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]
Mirroring/Lawful
Intercept
The lawful interception routable LI shim header session-id and intercept-id were not
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]
NAT
In very rare cases, fragmented NAT traffic could have triggered an MS-ISA reset.
[202382-MA]
WiFi Offload and

Aggregation
If, after a reset of the WLAN-GW IOM 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. This issue has been resolved.
[200081-MA]
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]
For HTTP proxy traffic, the host field in the HTTP header was used for expression
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]
Application
Assurance
235
Resolved Issues
System
Unusual error events related to the BITS framer may have been generated on all nodes
equipped with the first generation SF/CPM cards. In addition, BITS clock synchronization
may not have functioned correctly on this type of CPMs. This was only an issue in Release
11.0.R15 and has now been resolved. [201414-MA]
OSPF
OPSF LsUpdate authentication failures 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 amount
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]
In rare cases, if the far-end node brings down a BFD session and the BFD notification is
not received because of the data-path failure, then the tmnxEqDataPathFailureProtImpact
event may not have been generated. This issue has been resolved. [192889-MI].
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
An erroneous trap reporting that a 7750 SR-12e fan tray has been removed and inserted is
no longer raised. [190633-MI]
Configuring the dynsvc-password under configure system security password in

combination with enhanced password rules may have led to failures when executing a
saved configuration file. This issue has been resolved. [196318-MI]
MLPPP
ARP request packets were not able to egress on a VPRN/IES spoke-SDP interface over an
MLPPP-bundle network interface. This issue has been resolved. [195077-MA]
IS-IS
After a configuration rollback that involves an IS-IS router-id configuration change, IS-IS
would not be restarted to make the newly-configured router ID active. This issue has been
When exporting IS-IS routes from one instance to another, it was possible to get into a state
where prefixes were incorrectly exported. This only happened when IS-IS databases from
each instance were not properly isolated. Workarounds to this problem were to modify the
IS-IS export policy or to avoid the problem by properly isolating IS-IS databases from each
instance from each other. This issue has been resolved. [194871-MA]
HW/Platform
System
236
Resolved Issues
In rare cases, the standby CPM/CFM could have reset after BGP ran out of memory
resources. This issue has been resolved. [192757-MI]
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]
BGP Multi-homing
After a reboot, a node capable of becoming the Designated Forwarder (DF) for a site may
not have become a DF until after the Site-Activation-Timer (SAT) expired, although the
other PE had already become the non-DF. This would have caused an outage to the multihomed site for a period of SAT. This issue was introduced in Release 11.0.R4 and has now
MPLS/RSVP
An RSVP path message with a tunnel ID equal to zero (0) is no longer silently dropped.
[190941-MI]
mVPN
In certain scenarios where the (S,G) state of a group in an intersite-shared mVPN had timed
out, enabling intersite-shared kat-type5-adv-withdraw later would not cause the sourcePE to withdraw the source-AD BGP NLRI for that (S,G) entry. This issue has been
Services General
Removing an R-VPLS service that is referenced by an interface may have caused some
specific service configurations such as NAT, L2TP, or NTP to be deleted. A workaround
was to first remove the allow-ip-int-bind statement from the VPLS before removing the
service. This issue has been resolved. [195647-MA]
When a multi-chassis ring (MC-ring) is configured with fast BFD timers and the port on
one side of the MC-ring is shut down, the other side now goes into the broken state.
Previously, the other side may have incorrectly remained in the connected 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]
Subscriber
Management
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
When configuring a new interface in an R-VPLS configuration, traffic on an existing

interface could have been dropped when associating the new interface with a VPLS that did
not exist. A workaround was to configure the VPLS service prior to associating the new
interface to a VPLS. This issue has been resolved. [193574-MA]
TMS
An IES tms-interface can now be configured for certain routing protocols. Previously, this
was not supported and resulted in the following error when the configuration file was
executed (for example, after system reboot): CRITICAL: CLI #1002 The system
configuration is missing or incomplete because an error occurred while processing the
configuration file. Configuration files saved in releases prior to 11.0.R15 must still be
manually updated before they can be executed. [188107-MA]
BGP
237
Resolved Issues
Video
Having both an isa-video MS-ISA and a non-isa-video MS-ISA present on an IOM3 card
could have caused either video FCC/RET degradation or egress multicast traffic
duplication on LAG ports on the same IOM3. Refer to TA 14-1441 for details. This issue
238
HW/Platform
Some XFPs may have failed initialization after the associated MDA/XMA reset, and
generated the message SFF Read failure. For these XFPs to become operational, they had
to be re-inserted or the IOM/IMM/XCM holding them had to be soft-reset (clear card x
soft). Refer to TA 14-1318 for details. This issue has been resolved. [192136-MA]
System
Interrupting a recursive Secure Copy (SCP) prior to all files being copied will no longer
result in all files reporting incorrect timestamps and file sizes. [192470-MI]
PPP
If a protocol reject is received at the LCP level, LCP may have incorrectly remained in the
stopped state, depending on subsequent protocol messages. A workaround was to toggle
the administrative state (shutdown/no shutdown) of the MLPPP bundle or the PPP channel
to recover the link and allow LCP to attempt to renegotiate again. This issue has been
LAG
On an active/standby LAG, switchover time from standby to active may have been longer
than expected if a scheduler policy was applied to that LAG. A workaround to reduce the
switchover time was to change the Scheduler Run Minimum Interval to a low value with
this CLI command: configure card <> virtual-scheduler-adjustment sched-run-min-int
0.01. This issue has been resolved. [191556-MI]
Executing the tools dump map-to-phy-port lag x service y command on a 7450 ESS-1,
7750 SR-1, or 7710 SR chassis could have resulted in a node reboot. This issue has been
IPv6
Pinging an IPv6 address would fail if the ping destination address was configured on a
local interface that was down, even if it was configured on a redundant node and was
reachable. Transit traffic was not affected. This issue has been resolved. [190748-MI]
BGP
Creating a BGP peering policy with remove-private specified could have resulted in a
failure of all dynamic host BGP peers that made use of this policy, resulting in the event log
message: The system could not set up a BGP Neighbor for host ip-address on SAP: sapid, service: service-id. BGP peering attributes discarded: false. Description: Generic error.
Also, when a BGP peering policy was created through SNMP, setting
tBgpPrngPlcyRemovePrivateASLmtd to false was accepted and could have resulted in
Resolved Issues
similar events. A workaround was to leave this value unchanged. This issue has been
An MP-BGP message that contains multiple updates for the same prefix no longer results
in a High-Availability CPM/CFM switchover. This issue occurred in rare cases on
Multicore CPM/CFM systems. [193575-MA]
MPLS
A strict-hop cspf-enabled LSP path may have failed to set up if the no advertise-subnet
option was configured under OSPF point-to-point interfaces along the path of the LSP. This
LDP
Reception of corrupt LDP messages could, in rare cases, have resulted in a reset of the
standby CPM or CFM. This issue has been resolved. [190064-MI]
Subscriber
Management
After two High-Availability CPM/CFM switchovers, a node configured for

Wholesale/Retail could have entered a state that would not allow creation of new SRRP
instances, and would have generated the CLI error message: MINOR: VRRP #1156
Subscriber interface, including retail interface, has not defined a gateway address for some
subnet. To add a new SRRP instance when the node was in this state, either all SRRP
instances had to be removed or a full node reboot had to be performed. This issue has been
TMS
In rare cases, when a TMS interface was shut down or became operationally down due to
configuration changes affected while routes were added or deleted to the route table, the
system may not have released memory from the ISA memory pool, causing system
memory depletion over time. To recover, all TMS interfaces had to be deleted, then
recreated. This issue has been resolved. [189649-MI]
Wifi Offload and

Aggregation
Continuously bouncing GTPv2 peers on a WLAN GW could have resulted in a standby

CPM reset after an extended period of time. This issue has been resolved. [186227-MA]
GRE-encapsulated Subscriber Host-Connectivity Verification (SHCV) ARP frames that

were destined to a UE always had the IEEE 802.1Q Drop Eligible Indicator (DEI) bit
incorrectly set to one (1). This issue has been resolved. [191211-MI]
Lawful Intercept
Routable LI destinations (layer-3-encap) resolved by an IGP shortcut did not have the
MPLS TTL set to 255; instead a very low value was used, which could have caused LI
packets to expire in transit. This issue has been resolved. [193617-MA]
OAM
Mtrace failed when a local interface that was down had the source IP address or subnet
specified in the command. This issue has been resolved. [193205-MI]
239
Resolved Issues
HW/Platform
DHCP
The system now recovers gracefully from certain transient errors in the switch fabric.
[184482-MA]
An internal link in the switch fabric could in very rare cases have gone into a faulty state,
resulting in egress FCS error events and service impact. To recover from this situation, the
card reporting the egress FCS errors had to be reset. This issue has been resolved.
[189372-MA]
Performing a Minor ISSU from Release 11.0.R11 or earlier to a target Release of 11.0.R12
resulted in the following cards going into and remaining in a failed state with an error
message Incompatible FPGA version after the CPM switchover to the new software
version: imm-1pac-fp3 and imm-2pac-fp3 on 7750 SR and 7450 ESS; xcm-20 and xcm-16
on 7950 XRS. A subsequent manual clear card command (hard reset) for the card to
upgrade the firmware and come into service was required. As of Release 11.0.R13 (i.e., any
ISSU upgrades to Release 11.0.R13 onwards) Soft Reset is blocked for these cards during a
minor ISSU and the cards will no longer go into a failed state. CLI messages during the
ISSU (to Release 11.0.R12 onwards) may incorrectly report that these cards can be Soft
Reset. [191100-MI]
Performing a Major ISSU from a Release 10.0 image prior to 10.0.R18 to Release 11.0.R12
resulted in the following cards going into and remaining in a failed state with an error
message Incompatible FPGA version after the CPM switchover to the new software
version: imm-1pac-fp3 and imm-2pac-fp3 on 7750 SR and 7450 ESS. A subsequent
manual clear card command (hard reset) for the card to upgrade the firmware and come
into service was required. As of Release 11.0.R13 (i.e., any ISSU upgrades to Release
11.0.R13 onwards), the cards will no longer go into a failed state and are hard reset
automatically during a Major ISSU as expected since these cards do not support Soft Reset
in Release 10.0. [191100-MI]
Under high-load conditions and when new lease-states are getting established, if the DHCP
relay immediately releases the just-created lease-state(s) because of limit hits or other
reasons, normally the lease-states are removed again on both DHCP server and relay.
In rare cases, the lease-state would have been recreated a few milliseconds after processing
the deletion on the fail-over DHCP server because of a delayed Ack received via MCS, and
the result was an inconsistent IP address on the DHCP server, unresponsive for a time equal
to the Maximum Client Lead Time (MCLT). This issue has been resolved. [166634-MI]
240
When using a dual-homed DHCP server fail-over setup with prefixes configured as accessdriven and with a hold time configured, some DHCP leases could have gone into a state in
which they were bouncing between stable and held. The workaround was to disable
lease-hold-time. This issue has been resolved. [183498-MI]
When the name of a local-dhcp-server started with a number, the show router dhcp localdhcp-server name summary CLI command failed to display the associated interface. This
was not an issue when the local-dhcp-server name started with a letter. This issue has been
Resolved Issues
System
CPU Protection incorrectly flagged a LAG port as exceeding the link-specific-rate when a
mix of LACP and other packets destined to the control plane arrived on that port for a
consecutive number of seconds equal to the configured link-specific-rate. This problem
only impacted 7950 XRS and 7750 SR-7/12/12e equipped with SF/CPM5. The
workaround was to configure the link-specific-rate as max. This issue has been resolved.
[187967-MI]
LAG
Both sides of an MC-LAG without LACP enabled may have incorrectly displayed MCLAG status as standby. For example, this could occur when all ports of one MC-LAG side
were made administratively down, and afterwards, some ports of the active side were also
made administratively down. This issue has been resolved. [182313-MI]
BGP
When peer tracking was enabled and the BGP neighbor configuration was modified
through the user interface, the BGP peer may have been displayed as disabled, although the
session was established. This issue has been resolved. [175199-MI]
BGP convergence may have been delayed in scaled configurations that included defaultroute-target. This issue has been resolved. [186671-MI]
LDP
If received LDP FECs result in LDP resource exhaustion, now only the LDP interfaces to
which these FECs are resolved will be shut down. [157642-MI]
QoS
When a LAG member port transitioned to an operationally-up state, traffic impact may
have been higher than expected if the LAG was configured with adapt-qos distribute and
had a large number of SAPs with associated queues. The problem was not observed if there
was at least one other operationally-up port in the same LAG on the same forwarding
complex. This issue has been resolved. [188743-MA]
In rare cases, IP traffic egressing from a network interface via a Layer-2 service SDP
binding may have been incorrectly reclassified if the same forwarding complex contained
SAPs that were using sap-egress policies including IP criteria. This issue has been
Services General
Short flaps (sub-second) on the access side of a BGP MH site that was the Designated
Forwarder (DF) in a VPLS topology might have caused a Layer-2 loop for a very short
duration. This issue has been resolved. [189547- MA]
Subscriber
Management
When accounting statistics collection is enabled, the following log event was sometimes
generated after a CPM or CFM High-Availability switchover:
SUBMGR:sbmAcctCollectStatsAndSend Collecting stats took too long. In rare cases,
the switchover also resulted in an active CPM or CFM reset. This issue has been resolved.
[181655-MA]
Some Python cache entries were not synchronized by MCS when the MCS was not in sync
during a CPM/CFM switchover on the MCS active node. This issue has been resolved.
[186464-MA]
241
Resolved Issues
Incorrect encoding of the version field length in a X.509 Certificate Request generated by
the system could have caused some Certificate Authority servers to be unable to sign the
Certificate Request. This issue has been resolved. [189026-MI]
The system no longer tries to rekey an IPsec SA that was rejected by the peer with reason
INVALID_KE_PAYLOAD; instead, the rekeying of such IPsec SA is now correctly
stopped and cleared. [189771-MI]
WiFi Offload and

Aggregation
It was possible to erroneously remove the range configuration below WLAN-GW vlan-tagranges while it still contained an active UE. If errors similar to
BB_MGMT:wlanGwVlanRangeDel 2049.7:1-100 still has 1 cpm references were
already logged, applying new vlan-tag-ranges on the IOM where the UE was located would
have been rejected with BB_MGMT:bbIccHandleMsg reject type 36 (wlan-gw-vlanrange). To remove the inconsistency, the operator could either reset the IOM reporting the
issue or toggle the administrative state of the wlan-gw-group. This issue has been resolved.
[185305-MI]
NAT
If a deterministic subscriber needs a port-forward on a different outside IP address than the

one deterministically assigned, then this address has to be in the range specified in the
deterministic map to which the subscriber belongs. Persistent port-forward that does not
respect this new condition failed to be restored. This issue has been resolved. [183451-MI]
Application
Assurance
If the application-assurance port-recorder configuration was removed without first

removing any application references, it would then be impossible to remove those
referenced applications from application-assurance policy. This issue has been resolved.
[190088-MI]
The MS-ISA may have rebooted when attempting to perform HTTP Enrichment on
fragmented packets. This issue has been resolved. [191205-MA]
IPsec
HW/Platform
242
The MIB descriptions for tmnxDDMTxOutputPower and tmnxDDMRxOpticalPower did

not indicate that the returned values were for internally calibrated optical transceivers. The
standard SFF-8472 specifies how to calculate the values in case of external calibration.
A mandatory firmware upgrade with various improvements is introduced for these line
card types: imm-1pac-fp3 and imm-2pac-fp3 on 7750 SR and 7450 ESS; xcm-20 and xcm16 on 7950 XRS. A Soft Reset is not allowed during an ISSU from an image prior to
Release 11.0.R12 to a Release 11.0.R12 or later image; hard reset must be used instead.
[181115-MI]
After performing a Minor ISSU upgrade from Release 11.0.R7 or earlier to a target release
between Release 11.0.R8 and Release 11.0.R10, or a Major ISSU upgrade from Release
Resolved Issues
10.0.R17 or earlier to a target Release between 11.0.R8 and 11.0.R10, the following event
may have been generated for ports on the imm-2pac-fp3/p6-10g-sfp/p6-10g-sfp:
MDADRV:xgig_FrmTribLanMode DCM failed to lock for unused port group. A clear of
the MDA was required to make the MDA function properly after such an event appeared.
XCMs no longer fail a Soft Reset when the XCM uptime is greater than 58 days. [185942MA]
CLI
File operations using FTP or TFTP failed if the hostname contained the - character. The
workaround was to use the IP address instead of the hostname. This issue has been
ATM
Egress statistics monitoring at the ATM PVC level for ports on an m4-atmoc12/3-sf-b
might have displayed an incorrect utilization. A workaround was to clear the ATM PVC
statistics prior to monitoring. This issue has been resolved. [185503-MI]
LAG
An MC-LAG member port will no longer flap on a High-Availability switchover. In prior

releases, if LACP was not enabled and the MC-LAG member port was administratively
disabled and re-enabled, the port would have flapped on a High-Availability switchover.
[186264-MA]
DHCP
Local-dhcp-server MCS peers that were out-of-sync for a short period of time could have
incorrectly triggered the DHCP failover server state to go partner-down. This, for
example, could have occurred when toggling the administrative state of a subscriber
interface with many hosts populated. Both DHCP failover nodes could have started to
allocate duplicated IP addresses resulting in conflicting data when going back in sync. A
workaround was to clear all PPPoE sessions with MAC addresses for which the conflict
was reported. This issue has been resolved. [186844-MA]
IS-IS
IS-IS could have become unresponsive and as a result could cause the active CPM or CFM
to reset when overload max-metric was configured while IS-IS used more than one
tunnel (ldp-over-rsvp or rsvp-shortcut). Also, with advertise-tunnel-link enabled, some
tunnels were no longer advertised after a clear router isis database. This issue has been
OSPF
An OSPF broadcast interface configured as priority 0 no longer rapidly transmits hello

messages when connected to a far-end interface configured with a point-to-point type
interface. [184035-MI]
When LDP-over-RSVP is enabled for OSPF, specifying multiple equal-cost paths per
prefix, where one path did not have a tunnel endpoint, will no longer result in system
instability. [184575-MA]
BGP memory usage could have increased substantially over time on dual CPM/CFM
Multicore-CPU systems after a double High-Availability switchover or after a standby
BGP
243
Resolved Issues
CPM/CFM reset followed by a High-Availability switchover. See TA 14-0819a for more

information. This issue has been resolved. [187536-MA]
Under some conditions, memory usage might have slowly increased over time in the
RTM/policies memory pool. This issue only occurred on nodes that had a BGP export
policy with AS-path match criteria and route churn (additions and removals of BGP routes)
and only on CPM/CFMs with a Multicore-CPU. See TA 14-0827a for more information.
Starting in Release 11.0.R10, an extra hello message is now transmitted just before making
a TCP connection to address an interoperability issue with other vendors devices (see
issue 181135). That extra packet was being sent with an incorrect TTL value. The TTL for
those hellos are now correctly set to one (1) for link-LDP sessions and 64 for targeted-LDP
sessions. [185787-MI]
The system will no longer ignore a Label Request messages for a service FEC from a peer
that had already received the corresponding Label Mapping message for such service FEC
(Label Re-mapping). [186503-MI]
If there was a CPM/CFM High-Availability switchover while an LDP FEC was received
for the default route, some time later, an LDP interface could have become disabled with
the reason noResources, or an IOM could have reset. Traffic to the default route FEC
could also have been impacted after a dual CPM/CFM High-Availability switchover. The
workaround was to prevent the default route FEC from being created or advertised
throughout the network by means of export filters on the originating nodes of this FEC. See
TA 14-0871a for more information. This issue has been resolved. [186904-MA]
IGMP
Configuring mfib-allowed-mda-destinations might have caused multicast traffic not to

be forwarded out of some of the MDAs/XMAs listed in the command. A workaround was
to add and then remove an unrelated MDA/XMA to and from the configured list of
MDAs/XMAs. This issue has been resolved. [181985-MA]
PIM
Traffic for multicast group egressing on one or more IES spoke-sdp interfaces might have
been discarded on the ingress forwarding complex after a Major ISSU upgrade from
Release 10.0. This issue has been resolved. [188224-MA]
PPPoE
In very rare cases, the standby CPM/CFM could have failed to come up, resulting in the
following log event: PPPOE:pppoeRedUpdateSession Couldn't add/update SBM IPCP
session: Can not add internal ARP entry for IP. A workaround was to clear all PPPoE
sessions with the IP address for which the error was reported. This issue has been resolved.
[184753-MA]
QoS
For a port-scheduler-policy applied on a port or Vport, if any levels within a group had a
group weight greater than or equal to 64, then the initial bandwidth distribution between
these levels might have been incorrect. This issue has been resolved. [181681-MI]
Subscriber
Management
When a received COA RADIUS message was processed, a lookup was correctly first
attempted based on NAS-Port-Id and NAS-IP-Address. If no match was found, then both
LDP
244
Resolved Issues
Acct-Session-Id and IP-address were incorrectly used, where only a match on AcctSession-Id would have been correct. [172045-MI]
In rare cases, clearing a large number of subscriber hosts all at once could have resulted in
an active CPM/CFM reset.
When DHCP Option 82 information was changed because of applied DHCP configuration
option action replace, host-lockout was not being triggered. With DHCP configuration
option action keep, host-lockout was still working as expected. This issue has been
The active CPM/CFM no longer resets in some cases when an Acct-Interim-Interval

message is received from a RADIUS server for a Basic Subscriber Management (BSM)
host. [187077-MI]
VRRP/SRRP
Configuration Rollback in combination with an SRRP ID 4294967295 could have caused a

High-Availability switchover. This issue has been resolved. [179405-MA]
IPsec
Executing the show ipsec tunnel tunnel-name command at the same time that a techsupport file was being generated might have resulted in displaying incorrect statistics for
the tunnel and might also have raised critical alarms in the system such as
IPSEC_MGMT:UNUSUAL_ERROR Slot 2: ipsecTunnelISAKMPStatsGet: Error getting
stats from Racoon for tunnelId(153). These errors were benign. This issue has been
Accounting
XML accounting statistics collection and storage in the XML file could have failed for
SAPs from a specific IOM. For example, this could have happened when R-VPLS was
enabled and there were IES or VPRN SAPS from an older IOM type (i.e., iom2-20g or
older) that does not support R-VPLS. The CPM continued to collect and store retrieved
data even if not all requested data was returned from the IOM because of unsupported
features. This issue has been resolved. [183868-MI]
In configurations that have duplicate accounting policies for session accounting, only one
start message is now sent to each server, instead of two which was incorrect. [185950-MI]
NAT
When using L2-aware NAT with DHCP relay, unicast DHCP ACKs were sent on the
subscriber interface instead of the group interface. This was true for ACKs triggered by
both REQUESTs and INFORMs. This issue has been resolved. [186869-MA]
BFD
A very large discriminator value used by other vendors is now displayed correctly as an
unsigned integer. [185053-MI]
OAM
When a SAP was put in loop-back mode with the tools perform service id service-ID
loopback eth sap sap-id start ingress command and that SAP was a member of a Split
Horizon Group (SHG), its ingress BUM (Broadcast, Unicast and Multicast) traffic
component was dropped instead of being looped back. This issue has been resolved.
[187757-MI]
245
Resolved Issues
No technical issues were resolved in Release 11.0.R11 of SR OS since Release 11.0.R10.
The 10/100/1000 copper and 100FX/1G dual-rate optical transceivers (SFPs) are now
supported in Release 11.0.R10 on the FP3-based IMM with GE ports (p20-1gb-sfp).
[169378-MI]
A large amount of frame fragments received on an HS-MDAv2 (3HE06432AA) port due to

bad link quality will no longer, in rare cases, cause the HS-MDAv2 to lock up for incoming
traffic. A firmware upgrade is mandatory for this and a Soft Reset of an IOM with an HSMDAv2 is not allowed during an ISSU from an earlier release to Release 11.0.R10 or later.
Hard reset must be used instead. [177898-MA]
On a 7950 XRS or 7750 SR-12e, an Advanced Power EQualization (APEQ) module that
had a single power feed might have incorrectly reported through an alarm that both input
feeds were not supplying power. This issue has been resolved. [181520-MI]
The enhancement that was implemented in Releases 10.0.R8 and 11.0.R1 to allow IOM3XPs, IMMs, and XCMs to recover automatically from memory errors on the switch fabric
interface was not working correctly for all types of memory errors. Certain errors could
still have resulted in drop of multicast traffic across the switch fabric. [181634-MA]
When single-sfm-overload is configured in the router context on a 7950 XRS or 7750 SR12e, OSPF will no longer go into overload for a short period of time after a CPM HighAvailability switchover. [182683-MI]
Hold timers now operate on an sts192 when configured under the Ethernet context for 10G
ports in WAN mode. [183166-MI]
CLI
The monitor command for internal ports on an MS-ISA provisioned for Application
Assurance no longer incorrectly displays a zero (0) value for the Octets field in the output
when this value is not directly applicable to Application Assurance and now correctly
displays n/a instead. [171484-MI]
DHCP
An IP address that was released and immediately granted again by the active local-dhcpserver might have resulted in a false positive alarm dhcpServer lost sync with peer on the
standby failover local-dhcp-server side. Although it could have taken up to 60 seconds
before the next event was logged as dhcpServer back in sync with peer, the MCS
database was actually not out of sync. This issue has been resolved. [180776-MI]
RIP
When a RIPv1 request packet for a route is received, the response is now sent with the
correct metric if there is a match in the RIP database. [180903-MA]
HW/Platform
246
Resolved Issues
IS-IS
A full IS-IS SPF calculation will no longer result in adding and removing all IS-IS LFA
next-hops. [166340-MA]
LDP
When interoperating with other vendors devices, if the LDP hello timers were
mismatched, it was possible that the LDP session would not have been established. This
PIM
The threshold option in the mc-maximum-routes command was incorrectly using the
absolute number of multicast routes instead of a percentage ratio. This issue has been
PPPoE
Lower-than-expected PPPoE session setup rates could have been observed when
attempting to establish a large number of sessions at the same time. Performance may have
further degraded when PADO-delay was enabled. This issue has been resolved. [181563MI]
Services General
When a parameter is changed in the pw-template, the CLI command tools perform service
id service-id eval-pw-template is required to apply that change to the associated BGPVPLS/BGP-VPWS SDP-bindings. Prior to Release 11.0.R10, even without the command
tools perform service id service-id eval-pw-template, certain configuration changes such
as service-mtu or an operation such as CPM High-Availability, M-ISSU etc. would have
led to the system using the latest pw-template parameters to be advertised.
Incoming parameters from a PE used to also be compared with the latest pw-template configured parameters of the associated pw-template. Starting in Release 11.0.R10, the parameters are now compared with those of the binding to that PE or to the configuration of the
associated pw-template if there is no binding to that PE. [180191-MI]
Subscriber
Management
On nodes where Multi-Chassis Synchronization (MCS) had been up for a long time and the
MCS connection between two (2) MC nodes bounced, in very rare cases, MCS would stay
out-of-sync between those nodes. When this occurred, the system would have generated
unusual MCS logger events, such as Inserting seq # 2801647565, last entry seq #1 isn't
smaller or Peer 200.22.10.7 client 10 got unexpected entry seq # 0xa6dce2f7, last was
0x1. If MCS got into these states, to recover, the affected MCS peer had to be shut down
on both MC nodes at the same time and then enabled again one by one. [150468-MI]
In some scenarios where the configuration of a capture-SAP and the port or LAG was
changed to administratively down, the capture-SAP in CLI might have shown it was
administratively and operationally down, but packets were still forwarded. This issue has
A scaled number of l2-header IPoE subscribers that flapped, all having the same MAC
address and hosted under the same SAP, could have led to an unresponsive CLI when
service CLI commands were executed. This issue has been resolved. [179367-MI]
When all RADIUS servers for authentication were down and more than 150 sessions were
pending waiting for a response, DHCP sessions that did not require any RADIUS
authentication might have been delayed or even blocked. This issue could have been
mitigated by making use of RADIUS fallback or by configuring a pending-requests-limit
247
Resolved Issues
of a value lower than 150 in the radius-authentication-server CLI context. This issue has
PPPoE sessions synchronized to the standby MCS node but in a locally- or alarm-deleted
state due to certain issues could have caused a memory leak on the standby CPM/CFM of
the standby MCS node. The speed in which the memory was leaked depended on the
number of alarm- or locally-deleted MCS entries that could have been displayed using the
CLI command tools dump redundancy multi-chassis sync-database peer ip-address type
alarm-deleted | local-deleted detail. This issue has been resolved. [183408-MI]
VPRN/2547
The first vrf-import policy that set the preference value for an imported route also
incorrectly set the preference for the MP-BGP route in the base instance. Depending on the
internal order in which multiple vrf-import policies were evaluated, a different MP-BGP
route could have been selected as the best route. This issue has been resolved. [180001MA]
Video
In rare cases, a large number of consecutive updates to the Outgoing Interface List for
several PIM groups might have resulted in multicast traffic not being forwarded on some
egress or video interfaces for those groups. This issue only occurred when the video
interface was included in the Outgoing Interface List of the affected groups. The recovery
action was to manually clear the affected groups from the PIM database. This issue has
NTP
If NTP was configured and the admin tech-support command was executed, a number of
UDP sockets with port 123 were created on the system. If many admin tech supports were
taken, this could have resulted in a large number of sockets being stuck over time and
eventually, a depletion of the available sockets. A workaround was to perform a HighAvailability switchover. This issue has been resolved. [179771-MI]
Application
Assurance
Under unexpected traffic conditions in which multiple unique traffic flows concurrently
access the same subscriber policer instance, under-policing would occur. This issue has
Performing a MIB walk on the tmnxBsxAaSubPolicerTable or

tmnxBsxAaSubPolResExTable objects may have taken a significantly long time depending
on the number of AA subscribers configured. During this time, SNMP and CLI may have
been inaccessible. This issue has been resolved. A MIB walk or GET-NEXT of
tmnxBsxAaSubPolicerTable will now only return rows for a single subscriber. A MIB walk
of tmnxBsxAaSubPolResExTable will now return immediately if no subscribers in the
partition have exceeded policer resources. This issue has been resolved. [181888-MA]
BFD is no longer incorrectly detected as OpenVPN. [183176-MI]
sdp-ping and sdp-mtu are now supported with a P2MP spoke-SDP used as an I-PMSI in a
VPLS context. [154654-MI]
In rare cases, when multiple ports on the same IOM/IMM/XCM had EFM-OAM and/or
SSM configured and SNMP constantly polled interface statistics, an EFM-OAM session
with aggressive timers might have flapped. This issue has been resolved. [182377-MA]
OAM
248
Resolved Issues
Resolved in 11.0.R9
HW/Platform
Ethernet ports operating at 10 Mbps or 100 Mbps on an m12-1gb+2-10gb-xp MDA

(3HE07282AA/3HE07283AA) or an m12-1gb-xp-sfp MDA
(3HE07284AA/3HE07285AA) are now able to forward ingress frames with a frame size
that is a multiple of 128 bytes. A firmware upgrade is mandatory and a Soft Reset is not
allowed during an ISSU from an image prior to Release 11.0.R9 to the Release 11.0.R9
image or later (hard reset must be used instead). A Deferred MDA Reset is not supported
for this case (hard reset is mandatory). [173731-MI]
RADIUS
The RADIUS debug output now correctly displays framed-ipv6-pool. [179919-MI]
CLI
The file rd rf directory command no longer incorrectly returns an error message.

[179529-MI]
DHCP
When configuring lease-hold-time in combination with DHCP server failover, lease

database inconsistency might have occurred when a client was released. This issue has
A RADIUS Authentication-policy and DHCPv6-relay can now be provisioned together on

a regular (non-subscriber) interface in an IES or VPRN service. [179753-MA]
The clear router ospf statistics command no longer causes the next SPF to be executed at
an interval different from the first-spf-wait. [170212-MI]
Routes learned from Type 5 LSAs that were converted from Type 7 LSAs and have a
forwarding address equal to the broadcast address of the configured area-range would not
have been installed into the routing table. This issue has been resolved. [180377-MI]
When the individual GR families were included in the open message in combination with
the graceful-restart enable-notification feature, BGP peers might have bounced after an
upgrade. This issue has been resolved. [116610-MA]
A BGP session will no longer be torn down if an Update message is received with a Circuit
Status Vector (CSV) sub-TLV that is greater than one (1) byte when signaling an L2-VPN.
[173806-MI]
In some cases, adding and removing the disable-targeted-session command under the
router ldp targeted-session context could have resulted in an SDP bindings staying down
if the related LDP session had bounced while the disable-targeted-session command was
present. This issue has been resolved. [177941-MI]
If the operational state of multiple LDP interfaces toggled at exactly the same time and the
down time was very short, in very rare case, one of the re-established LDP sessions might
not have advertised one or more of the other LDP interface addresses to the remote peer,
OSPF
BGP
LDP
249
Resolved Issues
which led to missing LDP bindings on that remote peer. This issue could have been
avoided by configuring a hold-time up on all LDP interface ports to be one (1) or more
seconds. This issue has been resolved. [178658-MA]
A limitation in prior releases that required PIM to be explicitly enabled on multi-port

interfaces (LAG or APS group) where only IGMP was enabled, has been removed in
Release 11.0.R1 and higher. [144549-MI]
Layer-2 control traffic frames bound to the CPM/CFM received over a P2MP leaf were not
processed due to sanity checks in the packet processing added in Release 11.0.R1 that were
incorrectly trying to match the P2MP leaf label on the packet with the label associated to
the P2P instance. In this case, PIM-snooped frames were being dropped, causing no PIM
neighbors to be seen on the PE node when provider tunnel was enabled in a VPLS service.
QoS
Changing the CIR value in the service customer multi-service-site egress scheduleroverride scheduler CLI context wrongly set the CIR value to be the same as the PIR value,
even if the value of CIR was different than the value of PIR in the config command. When
the full configuration file was executed after a node reboot, this CIR value was also
wrongly set to the same as the PIR value, even if it was correct in the configuration file.
Also, an admin save command stored the wrong value in the configuration file. The
workaround was to set the egress scheduler override CIR value back to the correct value by
means of SNMP. This issue has now been resolved. See TA 14-0423a for more
information. [180898-MA]
Filter Policies
A High-Availability switchover will no longer occur after modifying a vrf-target and

applying a GRT export policy. [180577-MA]
Subscriber
Management
Removal of a PPPoE session because of session-timeout could have incorrectly triggered

an event stating subMgmtPppoe lost sync with peer to be logged on a standby MCS
node. Although it could have taken up to 60 seconds before the next subMgmtPppoe 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. [177636-MI]
It was possible to create a subscriber host without the use of RADIUS via a fallback-action
under configure subscriber-mgmt authentication-policy. If all defaults were not properly
configured, creation of the subscriber host failed, but would not have prevented the
creation of a RADIUS cache entry with incomplete data. If a subscriber host was
continuously trying to re-establish within ten seconds (the timeout period of the cached
RADIUS entry), the cache entry with incomplete data was never cleared. Even when the
RADIUS server was operationally up again, the subscriber host could still have failed to set
up since it was still reusing the cached RADIUS data. This issue has been resolved.
[178036-MI]
Executing the show service fdb-mac command simultaneously on two (2) different CLI
sessions might have caused a harmless unusual error event Slot A:
smgrSendTlsMacQueryAgeMesg: Malformed IOM response !. This issue has been
PIM
VPLS
250
Resolved Issues
VRRP/SRRP
When VRRP is configured on interfaces with local-proxy-arp enabled, the VRRP Backup
router will no longer incorrectly install ARP entries for replies received from the Master
router and point to the virtual MAC address (vrid-mac). [180367-MA]
L2TP
An empty Alc-Interface VSA replied in the RADIUS Access-Accept message to

authenticate an LNS session could have caused system instability. This issue has been
WiFi Offload and

Aggregation
A WLAN-GW sometimes responded with the wrong MAC address to an ARP request from
the UE, depending on the state of that UE. This issue has been resolved by always
responding with the same MAC address. [180958-MA]
Application
Assurance
Under unexpected RTSP session disconnect scenarios in which there were multiple RTSP
sessions within a single 5-tuple, the MS-ISA might have reset. This issue has been
OAM
p2mp-lsp-ping and p2mp-lsp-trace using LDP p2mp-identifier or ldp-ssm source and group
identifiers could have failed when a path went through an unnumbered LAG interface. This
An OAM mac-trace to an unknown destination within an I-VPLS could have resulted in a

High-Availability Switchover if there were a large number of SDP bindings in the B-VPLS
service. This issue has been resolved. [180874-MA].
Resolved in 11.0.R8
HW/Platform
CLI
The transmit (TX) laser of certain types of defective SFPs could have stayed up, even after
the related port had been administratively disabled. This issue has been resolved. [169285MI]
Taking a tech-support file with the admin tech-support CLI command could, in rare
cases, have triggered a small traffic interruption of a few hundred milliseconds on a
CPM/CFM, an IOM-2, or an older IOM version. This issue has been resolved. [172533MI]
In rare instances, the octet counters for ports on the imm-2pac-fp3/p6-10g-sfp/p6-10g-sfp

could have reported values that were larger than expected. This issue has been resolved.
[175345-MA]
Setting up an SSH session to some types of SSH servers might not have shown the
password prompt but would still have established the session if the right password was
entered. This issue has been resolved. [169361-MI]
251
Resolved Issues
System
Using file version check on a corrupted cpm.tim file will no longer result in a HighAvailability switchover. [167833, 174509-MA]
IPsec
In the case of IKEv1 phase-1 Delete informational exchange, the system ignored the phase1 indicated in the SPI of the Delete payload and deleted the phase-1 identified by the
header cookies of the ISAKMP message. This issue has been resolved. [173796-MI]
The admin certificate gen-local-cert-req command will now encode the common name
field as UTF8 instead of a printable string format. If a printable string is required for
compatibility, add the option use-printable to the request for legacy behavior. [176233MI]
DHCP
The status code NoAddrsAvail in DHCPv6 advertise messages can be inserted at two
different levels: the IA_NA option or the global DHCP message level. Starting from
Release 11.0.R8, the default for all applications will be the IA_NA option level. A systemwide configuration parameter adv-noaddrs-global is now available under the config>
system>dhcp6 context to add the status code at the global DHCP message level for
DHCPv6 relay on subscriber interfaces (esm-relay) and DHCPv6 server (server)
applications. [175061-MI]
OSPF
OSPF now shuts down if adding routes to the RTM fails, which is the same behavior as in
Release 10.0. Release 11.0.R1 had introduced a condition where OSPF would not shut
down if adding a route to the RTM failed. [172240-MI]
Older OSPF summary LSAs might not have been purged in the backbone area when interoperating with other vendors routers. This occurred when, due to configuration errors,
subnets were overlapped in a non-backbone area, and then these errors were later corrected.
An OSPF instance acting as an ABR to a stub area now advertises the default route that it is
configured to originate regardless of whether the OSPF instance has an active area 0
(backbone) adjacency. [176648-MA]
The route counters in the output of the show router bgp summary command were not
cleared after BGP shutdown or clear router bgp protocol when the node was in the helper
mode for a peer. This issue has been resolved. [120790-MI]
The IPv6-multicast BGP family should not have been used in a VPRN context since these
instances did not support IPv6-multicast route-tables. If an IPv6-multicast BGP family for
a BGP peer on a VPRN was configured and negotiated, the BGP peering was torn down
when a BGP update message with IPv6-multicast prefixes was received. The update-faulttolerance command had no influence on this behavior. This issue has been resolved.
[173926-MA]
If protocol-protection was enabled, ports added to a LAG were not correctly flagged for
L2TP protocol usage in cases where L2TP was already applied. This issue was not
observed when L2TP was applied afterwards or when the operational state of L2TP was
toggled after the LAG port configuration was executed. This issue has been resolved.
[172217-MA]
BGP
LAG
252
Resolved Issues
MC-LAG
Upon a multi-chassis LAG switchover, the newly active MC node might not have
transmitted traffic onto all LAG member ports. This issue has been resolved. [176779-MA]
Subscriber
Management
The system will now generate a trap when the FAT file system becomes corrupt for DHCP
persistency that would have resulted in a negative fill-level in the tools dump persistence
summary command output. When this trap appears, the compact flash should be repaired
with the file repair cfX: command. [144241-MI]
On scaled setups, information about the group interface SAPs were not properly
synchronized using MCS and not all information would have been present in the output of
tools dump redundancy multi-chassis srrp-sync-database. This issue has been resolved.
[172075-MI]
Static routes created by Dynamic Services scripts might have failed to be deleted after a
Minor ISSU upgrade to Release 11.0.R7 if they were created before the standby
CPM/CFM was upgraded. It was recommended not to perform a Minor ISSU when static
routes created by Dynamic Services scripts were in operation. This issue has been resolved.
[174659-MA]
Multi-chassis synchronization (MCS) failed to synchronize with a standby node of a

numbered IPoE subscriber host when allow-unmatching and populate-host-routes were
enabled for a subscriber-interface and address. As soon as allow-unmatching-subnets or
populate-host-routes was removed, MCS would recover. This issue has been resolved.
[176145-MI]
When relaying a DHCPv6 message, the hop-count value is now correctly incremented.
[177088-MI]
VRRP/SRRP
The MAC address of a VRRP instance could not be the same as the MAC address of the
parent interface, or the MAC addresses of any other IPv4 or IPv6 VRRP instances under
the same interface. In addition, the MAC address of an SRRP instance could not be the
same as the MAC address of the parent interface. This issue has been resolved. [169672MI]
WiFi Offload and

Aggregation
Invalid DHCP information could have been sent in the RADIUS Access-Request DHCPoptions VSA upon creation of an ESM host, or for promoted UEs when the RADIUS
authentication was triggered by a data packet different from a DHCP request. This issue
could have started to appear when more than 256K different hosts had ever been created on
the MS-ISA card that was trying to set up the ESM host. This issue has been resolved.
[177033-MA]
In scenarios where the PGW response to a GTP request came with a different source IP
address than the peer IP address in the FTEID, the maximum number of GTP session
requests could have hit a limit of 32K, resulting in the failure to set up any additional
sessions. This issue has been resolved. [177891-MI]
Reception of IPv6 PPPoE messages for a subscriber that had no IPv6 configured could, in
rare cases, have resulted in this unusual error event on a 7750 SR-c12 or 7750 SR-c4: Slot
A: iomRedAmIActive: Called with MySlotNum 2 - is this OK? Although the error was
innocuous, the issue has been resolved. [175716-MI]
PPPoE
253
Resolved Issues
When deploying RTSP and SIP ALG where L2-aware NAT subscribers used DHCP, and
DHCP lease states were cleared manually, the MS-ISA might have reset. This issue has
In very rare cases, an IP packet with a malformed header that was being processed by the
MS-ISA card while the card was out of resources could have caused the card to reset. This
Prior to Release 11.0.R8, a single RADIUS accounting message from the MS-ISA could
have been lost when the active RADIUS server went down. Starting with Release 11.0.R8,
after the maximum retry count and timeout period of the RADIUS server that went down,
the MS-ISA RADIUS accounting message will be retried on a next available responding
server. [176768-MI]
Video
In rare cases, multicast traffic might not have been forwarded to the video interfaces after a
node reboot. This issue has been resolved. [178594-MA]
Application
Assurance
If statistics collection was being performed on a specific traffic flow that was being
terminated, the MS-ISA might have rebooted. This was extremely unlikely to occur due to
the periodic nature of statistics collection and flow-termination timing. This issue has been
OAM
Configuring an invalid VPLS service name (e.g., starting with a digit) in the IES or VPRN
interface context is now correctly blocked in SNMP and CLI. [132476-MI]
An ETH-CFM configuration with a long domain association name could have resulted in a
truncated line in the configuration file, which would then have failed to execute after a
node reboot. This issue has been resolved. [173551-MI]
NAT
Resolved in 11.0.R7
HW/Platform
New firmware with various improvements for the following IMM types has been
introduced:
-
imm-2pac-fp3/p1-100g-cfp/p1-100g-cfp
imm-2pac-fp3/p10-10g-sfp/p1-100g-cfp
imm-2pac-fp3/p10-10g-sfp/p10-10g-sfp
imm-2pac-fp3 /p6-10g-sfp/p6-10g-sfp
imm-1pac-fp3 /p1-100g-cfp
This firmware upgrade is mandatory and a Soft Reset is not allowed during an ISSU from
an image prior to Release 11.0.R7 to the Release 11.0.R7 image or later (hard reset must be
performed instead). A Deferred MDA Reset is not supported for this case. [157212,
157214-MI]
254
Resolved Issues
New firmware with various improvements for the imm3-40gb-qsfp card has been
introduced. This firmware upgrade is mandatory and a Soft Reset is not allowed during an
ISSU from an image prior to Release 11.0.R7 to the Release 11.0.R7 image or later (hard
reset must be performed instead). A Deferred MDA Reset is not supported for this case.
[161786-MI]
Switch fabric parameters have been tuned on all imm-2pac-fp3- and imm-1pac-fp3-based
IMMs in Release 11.0.R7, resulting in a mandatory hard reset during an ISSU. A Deferred
MDA Reset is not supported for these cases. A hard reset must be performed on these cards
during ISSU if the starting release is prior to Release 11.0.R7 and the target release is equal
to or after Release 11.0.R7. [166686-MA]
An IOM3-XP will no longer reset during the execution of the admin tech-support CLI
command if it is equipped with two (2) m4-choc3-ces-sfp MDAs. [167065-MA]
When subscriber statistics were collected by the CPM, a slow or non-responsive HSMDAv2 due to a hardware or software issue might have resulted in degraded service
performance. A reset of the HS-MDAv2 was required to restore the service. This issue has
AC rectifier failure event tmnxEqPowerSupplyPemACRectAlm (CHASSIS #2111) was

shown when a power supply was configured as DC. This issue has been resolved. [172475MI]
CLI
In rare scenarios, the active CPM/CFM might have reset if the terminal window was left
unattended for longer than idle-timeout while the output on the window was waiting for
user input with prompt Press any key to continue (Q to quit) and the match pre-lines
output modifier was used. This issue has been resolved. [172345-MA]
System
The vRtrIfSpeed OID is no longer capped at 4,294,967,295 bps (32-bit counter). It is now a
64-bit counter that can correctly display higher speed values. [145501-MI]
When the source-address for application syslog was configured to use system, the out-ofband management IP address was incorrectly used in the syslog message when sending
filter log entries to syslog. This issue has been resolved. [161784-MI]
A * will now appear in the CLI prompt indicating a configuration change when the
administrative state of an MPLS path has changed. [164597-MI]
When removing an unprovisioned card, show system alarms will no longer report an
active alarm (i.e., Class IO Module : removed). [167610-MI]
RADIUS
A NAS-Port attribute included in a RADIUS authentication request could have had an

incorrect value because it was taken from the capture-SAP instead of the subscriber SAP.
This issue, which never was an issue for the RADIUS accounting request, has been
TACACS+
TACACS+ Authorization was active even when it was disabled by default in CLI. A
workaround was to explicitly configure tacplus no authorization in the CLI. This issue
was introduced in Release 11.0.R5 and has now been resolved. [171990-MI]
255
Resolved Issues
In certain interoperability scenarios with other vendors devices, using IKEv1 with the
same lifetime for both IKE SA and IPsec SA might have prevented the system from
deleting an expired IKE SA, causing the tunnel to remain down indefinitely. To recover, the
affected tunnel had to be cleared with CLI. This issue has been resolved. [169267-MA]
In case multiple IKE SAs (phase-1 SAs) are active at the same time, the system will now
use the original phase-1 SA (or its successor if the phase-1 SA was re-keyed) that was used
to establish a phase-2 SA to re-key the phase-2 SA when this is required. [170166-MI]
Filter Policies
When a community expression was configured to match on a fixed number of digits

through the { } operator, incorrect matching occurred when the input community contained
digit 0. This digit 0 (as well as the following digits) were ignored for evaluation,
allowing a community exceeding this fixed number of digits to match. This issue has been
BGP
A High-Availability switchover will no longer result in VPN-IPv4 routes becoming

unresolved in configurations with a large number of spoke-SDP bindings. [165386-MA]
An AS Path regular expression containing the ASN1* operator might have incorrectly
returned an incorrect AS Path containing an AS number not included in the regular
expression if the last AS number in the AS Path was different than ASN1. For example, the
regular expression 17561+ 9315* 38288* should have matched AS Path 17561 38288
but was also incorrectly returning 17561 38288 24394 because the last AS number 24394
was different than 9315. This issue has been resolved. [166152-MI]
Receiving a BGP anycast label that was explicit null would not have been installed. A
workaround was to use implicit null. This issue has been resolved. [166733-MI]
Using community replace in a vrf-export policy where route leaking was being used
might have resulted in some routes not getting properly leaked after toggling the
administrative state of a VPRN (shut/no shut) that was importing the leaked routes. A
workaround was to use community add. This issue has been resolved. [168864-MI]
If BGP preference was modified through an import policy and then the global BGP
preference was modified, the policy was not re-applied if the global BGP preference was
removed. A workaround was to enable triggered-policy and to use clear soft-inbound.
An IPv6-multicast UPDATE with a 32-byte IPv6 next-hop is no longer incorrectly rejected.

[174199-MA]
When queue overrides were defined on a SAP with CIR weights not being overridden,
incorrect values would have been displayed for weight and CIR weight in the output of the
CLI command show service id service-id sap sap-id. This was strictly a CLI display
issue. This issue has been resolved. [171619-MI]
When the number of configured queues on a 400 Gbps XMA card in an XRS chassis
exceeded 64K at ingress or exceeded 64K at egress, the surplus queues might not have
been created correctly on the XMA, causing traffic to be dropped. This issue has been
IPsec
QoS
256
Resolved Issues
The standby CPM/CFM might have failed to synchronize with the active CPM/CFM and
stayed in a reboot cycle when there was an Epipe configured with Link Loss Forwarding
(LLF) enabled, the local SAP port of that Epipe was in shutdown state, and the remote
Epipe instance signaled a fault. The workaround was to not shut down Epipe SAP ports
that had LLF enabled. This issue has been resolved. [167007-MI]
On nodes with more than 255 network interfaces, IP packets from IES or VPRN spokeSDP interfaces that were routed over these network interfaces might have been sent out
with an outer source MAC address of all zeroes. This could have resulted in some third
party devices to drop these packets downstream of the network interface. This was only an
issue in Release 11.0 and has now been resolved. [174294-MA]
Subscriber
Management
When ppp-policy PPPoE user authentication was configured as type pref-pap, PAP
initially was attempted and if that failed, it would fall back to CHAP. However, in case the
client replied a NAK with a protocol different from CHAP, PAP authentication was
incorrectly tried again. This issue has been resolved. [172130-MI]
WiFi Offload and

Aggregation
When the SSID name contained a space character, the output of the CLI command show
subscriber-mgmt wlan-gw ue incorrectly only displayed the part of the name in front of
this space character. This issue has been resolved. [169698-MI]
NAT
The python script did not always return the correct results for a DS-Lite query. The use of
the show command or tools command were the alternative to get the correct results. This
When deploying RTSP and SIP ALG, the MS-ISA might have reset when NAT flows were
created and then immediately cleared manually, or when an L2-aware subscriber was
deleted as a result of a promoted UE being removed. [171575-MA]
Cflowd
All routed traffic destined to a subscriber would have been sampled when Cflowd was
enabled on the ingress interface regardless of the Cflowd rate. This could have resulted in
wrong traffic rates at the collector. This issue has been resolved. [167521-MI]
OAM
lsp-trace with the DDMAP TLV option to a BGP labeled route failed at the egress ASBR
when the latter was configured with the advertise-inactive option in BGP and the BGP
labeled route was not active in RTM due to the presence of an IGP or static route for the
same prefix. This issue has been resolved. [166584-MI]
ldp-treetrace with the DDMAP TLV option of an LDP FEC stitched to a BGP labeled route
returned DSMappingMismatched error when BGP ECMP was enabled at the LDP-BGP
stitching LSR and the transport tunnel for the BGP labeled route was an LDP LSP. This
Services General
Resolved in 11.0.R6
257
Resolved Issues
HW/Platform
Some older systems might have reported that the fans were running at full speed when in
fact they were running at half speed. This issue has been resolved. [165307-MI]
An XCM reset will no longer occur if an admin tech-support command was issued while
an x40-10g-sfp or a x4-100g-cxp XMA was present in one of the two slots of the same
XCM and a subsequent admin tech-support was issued after the aforementioned XMAs
were replaced by any of the following C-XMAs in the same XCM slot:
-
cx20-10g-sfp
cx2-100g-cfp
cx6-40g-qsfp. [166552-MA]
On an 7950 XRS that was equipped with sfm-x20-b SFMs, if an XCM card was inserted
after a CPM switchover had taken place on this node, the newly inserted XCM might have
failed to come up and gone to failed state. [167300-MA]
Running the management port at half duplex on a 7950 XRS could, under certain
circumstances, have resulted in a management-port lock-up or, rarely, in an active CPM
reset, resulting in a High-Availability CPM switchover. [167723-MI]
During boot up, if there was a constant stream of characters received on the console port,
the boot process might not have completed and might have been delayed until the stream of
characters subsided. If this occurred, the standby CPM/CFM and line cards would not
come online. The probability of seeing this issue was higher with lower console port baud
rates (e.g., 9600 baud). This issue has been resolved. [168838-MI]
CLI
Using the rollback compare command while editing the candidate configuration no longer
results in a High-Availability switchover. [164571-MA]
System
When the source-address for application syslog was configured to use system, the out-ofband management IP address was incorrectly used in the syslog message when sending
filter log entries to syslog. This issue has been resolved. [161784-MI]
Creating and deleting long filenames (LFN) in a directory could have resulted in corrupting
the directory. Creating new LFN files would have failed while in this state. A workaround
was to temporarily create new files in 8.3 format until LFN files could have been created
again. The 8.3 filename must have been all uppercase and only a single dot, for example,
ABCD.TXT. The temporary 8.3 files could have been deleted after the LFN files started
working again. This issue has been resolved. [165385-MI]
The file dir CLI command could have taken a long time to execute if there were
thousands of files in the local compact flash or SSD directory that was being queried. This
Using admin display-config index will no longer cause a High-Availability switchover

on 7950 XRS when LAGs are configured. [167179-MA]
Using file version check on certain corrupted cpm.tim files will no longer result in a
High-Availability switchover. [167833-MA]
A TCP packet with an invalid TCP options length in its header that is sent to the CPM
because of filter logging will no longer result in a High-Availability switchover.
[166439-MA]
Filter Policies
258
Resolved Issues
IPsec
In some rare cases, a reverse IPsec route associated with a dynamic LAN-to-LAN tunnel
might not have been deleted properly when the remote traffic selector changed before
completely tearing down the tunnel. As a result, the IPsec route would have indefinitely
remained in the route table, pointing to an incorrect next-hop and preventing the route from
being used again by a tunnel. This issue has been resolved. [166680-MA]
NTP
A High-Availability switchover would have caused the system to forget that PTP was
configured as an NTP server source. This would have caused NTP to go into free-run if
there was no other NTP sources configured. If there was another valid NTP source
configured, it would have been acquired, but the system clock accuracy would have been
less than the accuracy obtained from the PTP source. The recovery solution was to
reconfigure PTP as an NTP server source after a High-Availability switchover. This issue
Routing
When Path-MTU Discovery (PMTUD) is enabled, the system no longer ignores the peer
Maximum Segment Size (MSS) advertised during the TCP connection establishment. If the
peer advertises an MSS lower than the local MSS, the system will reduce the local MSS to
the lower value. [165896-MA]
ASAP
When using G.832 framing, a payload type of UNEQUIPPED was always signaled
regardless of the encap-type. This issue has been resolved. [158508-MI]
IS-IS
A router might not have advertised an L1 summary address in IS-IS if the same L1
summary was advertised by another router. This issue has been resolved. [162958-MA]
The number of exported routes was counted incorrectly after a High-Availability

switchover. A modification (i.e., next-hop change) of an exported route would have
incremented the exported routes counter even if the actual number of exported routes had
not increased. To fully recover, the IS-IS instances needed to be deleted and recreated. This
IS-IS reports overload status to the Traffic Engineering database on a per-level basis. When
an IS-IS instance entered an overload state, there might have been a delay in the
transmission of IS-IS LSP with the overload bit set between the two levels. When the
config>router>mpls>retry-on-igp-overload option was enabled, MPLS was notified of the
overload on a per-IS-IS instance basis and thus, there was a chance that an RSVP LSP that
was retried due to an overload state in one IS-IS level might have been successfully reestablished via the router in overload with a path using links in the other level. This was
more likely to happen when the LSP retry-timer or p2p-active-path-fast-retry value was set
to a few seconds such that the LSP path was retried prior to receiving the IS-IS overload
notification for the other level. This issue has been resolved. [164579-MI]
IS-IS calculated the metric incorrectly for a LAG interface when the total bandwidth was
changed (e.g., addition/deletion of LAG members, toggle of port status, etc.) to a value
greater than +/- 34.4 Gbps. This issue has been resolved. [169571-MA]
When modifications were made in the BGP configuration related to peer-tracking, it was
possible that some peers would enter the disabled state when they should have been
BGP
259
Resolved Issues
established instead. A workaround was to toggle the peer (shutdown/no-shutdown). This

LDP
260
In very rare cases, a race condition could have caused the active CPM/CFM to reset and/or
switchover when a route's next-hop was changing in BGP. This issue has been resolved.
[163236-MI]
When modifications were made in the BGP configuration related to peer-tracking, it was
possible that some peers were established although they should have been disabled based
on the peer-tracking policy. This issue has been resolved. [164821-MA]
When a BGP session was disabled by peer-tracking-policy, the value of SNMP MIB object
tBgpPeerNgConnState for the session was incorrect. This issue has been resolved.
[165899-MI]
If update-fault-tolerance was enabled and the optional, transitive or partial bit was wrong in
the attribute flags for the atomic aggregate attribute, the update-errors counter would not
have been incremented and no log-event would have been generated. The flag itself was
fixed correctly when sending out the attribute. This issue has been resolved. [166224-MI]
Labeled IPv4 routes remained unresolved after the LSP which was used as transport was
bounced and had no bgp-shortcut configured. This issue has been resolved. [169668-MI]
TCP MSS was not increased to the maximum value when no tcp-mss was configured on
the interface level and when PMTU was configured and then a new LDP session came up.
Note that the config>router>ldp>peer-parameters>peer address in this context means
that address is the TCP transport address used by the peer, so all possible addresses that
could be used to connect to a peer need to be configured in peer-parameters. This is
necessary because the transport addresses to be used are only negotiated at LDP hello
adjacency setup. This issue has been resolved. [161619-MI]
When the mcast-upstream-frr option was enabled, it was possible that two LDP peers used
each other as an upstream LSR backup for an mLDP P2MP FEC. This was the case in
triangle topologies when one or both LSRs had at least one other branch for the same FEC
besides the link connecting them. In such a case, it was possible that the P2MP FEC state
might not have been cleared from one of the LSR nodes even after the user deleted all other
branches of the FEC. The workaround was to disable and re-enable the mcast-upstream-frr
option on the LSR which would clear the state. This issue has been resolved. [162902-MI]
vRtrLdpIfStateChange traps were incorrectly being generated if LDP went operationally

down due to resource exhaustion. This issue has been resolved. [165946-MI]
When an interface or its address was deleted and then re-added and that interface was
referenced in a targeted-session peer template within the local-lsr-id statement, the locallsr-id statement was deleted and then incorrectly re-added. The targeted LDP session,
however, came up with the system interface as the local LSR-ID. The workaround was to
make sure that the user manually deleted the local-lsr-id statement from the peer template
before deleting the interface configuration. This issue has been resolved. [167089-MI]
When a manual-targeted LDP session was configured to a peer, it took precedence over a
session to the same peer, auto-created using the peer template. The Hello adjacency was
updated dynamically and the targeted session remained up as expected. If the user
subsequently shut down the interface referenced in the peer template within the local-lsr-id
statement, the targeted session to the peer went unexpectedly down. This issue has been
Resolved Issues
QoS
Subscriber
Management
In rare scenarios with a large number of FECs, none of which were resolved, it might have
taken longer than expected for the results of the show router ldp bindings command to
display, or to generate a tech-support file, which also uses this command. This issue has
The headings Service-Id and Customer-Id are now displayed for every service in the
output of show qos sap-ingress association. [164827-MI]
Queue group names containing space characters are now delimited by quotes when
instantiated on access. Prior to Release 11.0.R6, access queue group names were not stored
correctly in memory and might have prevented the system from executing the
configuration file. [168241-MI]
Stale entries that remained in the multi-chassis synchronization database could have
affected subsequent leases. [164376-MI]
CLI allowed multiple RADIUS servers with the same IP/port combination which, in case
of admin-save, would have resulted in an invalid configuration that failed to execute at
reboot. This problem could have been introduced in all contexts where RADIUS servers
were configured. This issue has been resolved. [166849-MI]
ECMP load-balancing to identical RADIUS Framed-Routes/Framed-IPv6-Routes with

different next-hops was not supported for the following Wholesale/Retail scenarios:
-
A single Retail service having ECMP Framed-Routes with next-hops in two or more
different Wholesale VPRN services
A combination of Wholesale and Retail in a single VPRN service ECMP FramedRoutes with one or more local next-hops (regular subscriber interface; acting as
Wholesale) and one or more next-hops in different Wholesale VPRN services (linked
subscriber-interface; acting as Retail)
In these scenarios, a part of the ECMP load balanced traffic was dropped. This issue has
RIP
When a credit-control-policy was used with out-of-credit-action set to change-service-level

and with a filter configured in its definition, a PIR different from the default needed to be
specified or at renewal of the credit, filters were not removed. This issue has been resolved.
[166946-MI]
Unnumbered subscriber interfaces for IPoEv4 with relay to a local DHCPv4 server on the
same router was not supported. While the client saw a successful DHCP renewal, the
subscriber host lease state on the BNG was not extended, causing a premature
disconnection. This issue has been resolved. [167053-MA]
When 16 bytes of authentication-key was configured in RIP, the last byte was filled with
the null character. This issue would have impacted interoperability and ISSU when all 16
bytes of authentication-key were used, specifically when:
-
Upgrading from a previous release to Release 11.0.R1 through 11.0.R5
Performing an upgrade (including ISSU) from Release 11.0.R1 through 11.0.R5 to a

later release
The network included SR OS routers running any of the Release 10.0 or Release 11.0
up to 11.0.R5 mixed with those running Release 11.0.R6.
261
Resolved Issues
262
VPLS
An MSTP instance ID value greater than 255 had unexpected STP state behavior. This
MPLS/RSVP
When an RSVP LSP originated in an OSPF NSSA area and had as destination an ABR of
that area, for which the router-id (ip-address) maps to the default OSPF route, CSPF
automatically computed an inter-area LSP path by selecting the exit ABR among the
available ABRs. This selection was based on the lowest cost to the exit ABR. As such,
LSPs going to other ABRs of that same NSSA area would transit via the selected exit ABR
even if a direct lowest-cost intra-area TE path existed within the NSSA area. This issue has
MPLS-TP
Performing a manual switch operation on an MPLS-TP LSP by specifying the tunnel-id via
tools perform router mpls tp-tunnel manual id tunnel-id resulted in a code for a lockout to
be sent to the remote side (instead of the code for manual switch). The workaround was to
specify the LSP using the lsp-name via the tools perform router mpls tp-tunnel manual
lsp-name command. This issue has been resolved. [163258-MI]
BFD
Starting with Release 11.0.R6, it is no longer possible to enable uBFD on a LAG with
encap-type dot1q when SAP lag:0 exists in a VPRN or on a LAG with encap-type qinq.
Files containing such a configuration can no longer be executed on the system. [166775MI]
It was possible to create SAPs lag.0 and lag.* in services of the type PIPE (except Epipe)
when micro-BFD was enabled on the LAG. If this configuration was saved to a file, then
the execution of the file would have failed. This issue has been resolved. [166782-MI]
NAT
After VPRN shutdown, the active NAT pool remained active and the export route was still
present in the routing-table of the VPRN even though the VPRN was operationally down.
PPPoE
Creating or deleting a PPPoE host with an auto-generated subscriber name (subscriber-id)

that used circuit-id or remote-id as key could, in certain cases, have resulted in unusual
errors logged by the standby CPM/CFM (CRITICAL: LOGGER #2002 Base
B:SUBMGR:UNUSUAL_ERROR Slot B: sbmEiGetAddr: pParent == NULL ).
Service impact was possible upon a High-Availability switchover when the previous
standby CPM/CFM became active. As a precaution, only use as input for ppp-sub-id-key
either mac, sap-id or session-id. The other option was to make use of a SAP defsub-id. This issue has been resolved. [167590-MI]
Application
Assurance
AA subscribers will no longer remain in a pending load-balancing state indefinitely after

a reboot in configurations where a single service contains more than 65535 AA-enabled
subscribers. [167729-MA]
Resolved Issues
OAM
lsp-trace with the DDMAP TLV option of an LDP FEC stitched to a BGP labeled route did
not work when BGP ECMP was enabled at the LDP-BGP stitching LSR and the transport
tunnel for the BGP labeled route was an RSVP LSP. This issue has been resolved. [164974MI]
lsp-trace with the DDMAP TLV option of an LDP FEC stitched to a BGP labeled route
returned DSMappingMismatched error when BGP ECMP was enabled along with the
system-ip-load-balancing option at the LDP-BGP stitching LSR and the transport tunnel
for the BGP labeled route was an LDP LSP. This issue has been resolved. [164977-MI]
An SAA test with probe type lsp-ping or lsp-trace would have failed if it sent probes while
the RSVP LSP was in an operationally-down state, but would not have succeeded once that
LSP was back up. The only way to recover from the failed state was to clear and then reenter the SAA type. This issue has been resolved. [166766-MI]
Deleting a G.8032 sub-ring control SAP from an Ethernet ring control VPLS could have
caused system instability. This issue has been resolved. [167122-MA]
Resolved in 11.0.R5
HW/Platform
CLI
IPsec
The firmware for SF/CPM2 and CFM-12g has been updated to address an issue where runt
frames entering the Ethernet management port (out-of-band) would slow down the
connection, and another issue where the management port bounced under congestion when
in half-duplex. [151110, 151112-MI]
Port linkDown alarms might not have been shown again in the output of show system
alarms CLI commands after replacing or re-seating the MDA, XMA, IOM/IMM or XCM.
Power supply alarms are now generated for APEQ faults on the 7750 SR-12e. [164824-MI]
Rollback now correctly reverts to a previously saved rollback checkpoint if new queue
groups are configured and linked to interfaces after this checkpoint was created.
[162959-MI]
The filter log now displays the Fragment Offset and Identification for packet fragments,
and also suppresses the source/destination Layer 4 port of fragments without a TCP or
UDP header. [163828-MI]
The default value of the hold priority of a template-based RSVP LSP of type mesh-p2p or
one-hop-p2p was incorrectly set to seven (7) (the lowest hold priority). This has now been
changed to the correct value of zero (0) (the highest hold priority). [165591-MI]
IPsec dynamic LAN-to-LAN tunnels terminated on a 7750 IPsec Dynamic Gateway that
were configured with X.509 certificates might not have been re-established after a CPM
switchover if there were multiple IPsec gateways configured on the same tunnel group. The
recovery action was to clear the IPsec gateway with the clear ipsec gateway CLI
263
Resolved Issues
command. For more details, refer to TA 13-0844. This issue has been resolved. [161775MA]
A key update with the CLI command admin certificate cmpv2 key-update for certificate
management required the hash-alg field to be included in the CLI command, even when it
used the SHA1 default; otherwise, the transaction would not have been requested and no
error was returned. Attempting the same key update with SNMP-SET always returned
inconsistentValue, even if the hash-alg field had been included. This issue has been
CLI rollback would have failed if the scope of an embedded filter, which was embedded
into a filter with a higher numerical filter-id, changed from embedded to template or
exclusive as a result of the rollback. To avoid the issue, the embedding must have been
removed manually before rollback. This issue has been resolved. [162079-MI]
After a High-Availability switchover, shared subinsert filter copies might have lost any
embedding entries. A workaround was to remove and to re-add the filter embedding. This
ICMP packets ingressing on the outband management interface can now be matched
properly by the Management Access Filter. [163357-MI]
When configuring CPM-filters that make use of port-lists containing port-ranges,

unexpected failures might have occurred when the CPM CAM was nearly full. When this
situation occurred, further CPM filter configurations might have also failed, even after
reducing the CAM utilization. This issue could have been avoided by making sure that
enough CPM CAM resources were available. If the problem occurred, the workaround was
to delete a few (at least 2) CPM filter entries that were changed before and re-configure
them. This issue has been resolved. [164121-MI]
LAG
LAG bandwidth at creation and before adding any ports to it was incorrectly set to 100M
instead of zero (0). This issue has been resolved. [165767-MI]
PIM
mVPN co-located Rendezvous Points (RPs) without anycast is now supported but with the
limitation that RPs should be configured only on PE routers in no-intersite-shared
scenarios. [163972-MI]
LDP
Deconfiguring BFD at the router interface level on an LDP interface that was registered
with BFD (bfd-enabled) would have led to an error when loading the configuration file.
BFD needed to be explicitly un-provisioned at the LDP level. This issue has been resolved.
[121314-MI]
IP Multicast
PIM CPU usage was higher than expected when processing hundreds of IGMP snooped
messages per second in a VPLS. Consequently, this could have also increased the multicast
traffic forwarding delay upon receiving an IGMP join. [164782-MI]
QoS
Operational WRED slope values are no longer recalculated when the slope policy is
applied to a port and a new network queue policy changes the shared pool memory size.
[60919]
Filter Policies
264
Resolved Issues
Routing
IPv6 packets with a destination address equal to a far-end IPv6 interface address are now
sent out correctly on that interface if the IPv6 interface address has a /127 subnet. They are
no longer erroneously sent to the CPM/CFM to be forwarded by the control plane.
[163466-MA]
OSPF
An OSPF vulnerability left open by the OSPF VU-130513-1 (RFC 2328) regarding the
validation of an LSAs Link State ID and Advertising Router ID has been resolved.
[161314-MA]
In Release 11.0, when an interface was changed to unnumbered and that interface was used
in OSPF, OSPF would wrongly select 0.0.0.0 as the designated router. A workaround was
to change to no interface-type under config router/service ospf area interface. That
would make the interface point-to-point and the operation was corrected. This issue has
In certain scenarios, while using OSPF as PE-CE routing protocol, a PE may incorrectly
generate a type 5 external LSA for the default route even if the default route is learned via
the PE-CE adjacency. This issue has been resolved. [163160-MI]
VPN-IPv4 routes that were flagged as invalid might not have been reflected to all routereflector clients if the routes flapped. A route-reflector would have marked routes as
invalid if there was a local VPRN configured with an import target matching the routes
received but there was no valid tunnel to the next-hop of the route. A workaround was to
ensure that all VPN-IPv4 routes were marked as valid by configuring a tunnel in the VPRN
to all next-hops. This issue has been resolved. [161331-MA]
When a local VPN-leaked route was not the best route, it was withdrawn from the BGP ribin (PE-CE) but the rib-in was not re-computed for other possible changes that the
withdrawal might have caused. This issue, which was only applicable if Deterministic
MED was enabled, has been resolved. [161720-MI]
MPLS/RSVP
The fast-reroute type in an LSP template of type mesh-p2p would have reverted to the
default value of no node-protect if the user performed an admin save and then rebooted
the system. The workaround was to perform an admin save detail before rebooting. This
Services General
An Epipe multi-homed scenario with BGP-VPWS changing the VE-ID after shutting down
BGP-VPWS could have resulted in a state with no designated forwarder. The workaround
was to change the VE-ID dynamically without shutting down BGP-VPWS in the service.
Subscriber
Management
In certain BNG multi-homing scenarios without MC-LAG on the subscriber interface, an

erroneous DHCP-release could have been sent by the standby node which could have
impacted the subscribers. This issue has been resolved. [162851-MA]
MCS records with a remaining lease time that was less than or equal to zero (0) could have
impacted new subscribers in certain scenarios. This issue has been resolved. [162852-MA]
It is no longer possible to delete a Web Portal Protocol (WPP) node under a group-interface
that is not shut down first. [162925-MI]
BGP
265
Resolved Issues
When using a credit-control-policy on policers with out-of-credit-action set to changeservice-level and a filter configuration in the definition, a PIR different from the default
one needed to be specified because the default PIR would have caused system instability
otherwise. This issue has been resolved. [164719-MA]
A Routed-VPLS service does not support Multicast-VLAN-Registration (MVR). When

allow-ip-int-binding was already enabled in the VPLS service, configuring mvr fromvpls or mvr to-sap below the SAP was correctly prevented. However, first configuring
SAP mvr from-vpls or mvr to-sap and then enabling allow-ip-int-binding was
incorrectly not blocked and could have resulted in a failure to execute the configuration file
after a node reboot. This issue has been resolved. [163006-MI]
In a VPLS service, the application of vsi-export/import policy to BGP-MH routes was

incorrectly skipped. This issue has been resolved. [164112-MA]
VRRP
If a VRRP authentication-key was configured with a string that was eight (8) characters
long, it would have been truncated to seven (7) characters in the VRRP message. This
caused the remote node to fail to recognize the VRRP message as the keys no longer
matched. As a workaround, the authentication key should have been configured up to a
maximum of seven (7) characters. This issue has been resolved. [163841-MA]
mVPN
State changes or configuration changes to LAG ports that belong to a VRF interface might
have impacted the forwarding of multicast traffic when new IGMP joins were received on
other interfaces within the VRF. This issue has been resolved. [166700-MI]
NTP
When NTP was operational with a chosen server, and there was a large time adjustment
from that server, NTP might not have been able to recover the time. Logger events
ntpd:CPMDRV:cpmPchipAdjustTimer deltaUsec value out of range or
ntpd:NTP:clock_update ATTN: Clock exceeded panic threshold would have been
generated when this occurred. To recover from this situation, NTP should have been
restarted with configure system time ntp shutdown, followed by no shutdown. This
IGMP
Receiving an IGMP (*,G) join on an interface, for a group configured within the PIM SSM
group range but that did not have an SSM translation, would have momentarily deleted the
static (S,G) entry for the same group on the same interface. The workaround was to
configure SSM translation under IGMP. This issue has been resolved. [160753-MI]
NAT
In Release 11.0.R4, the MS-ISA card might have reset because of a memory leak issue
when downstream fragmentation of IPv6 packets was performed in NAT64 and tcp-mssadjust was enabled. Forwarded fragmented IPv6 packets might also have been corrupted.
The system no longer enters into an inconsistent state while setting the port-forwarding
limit to 1023 in an outside Layer-2-aware NAT pool and while creating port-forwards
without specifying the inside-port and the outside port. [163620-MA]
VPLS
266
Resolved Issues
Configuring multiple Cflowd collectors reachable through the management port on a 7950
XRS could have caused congestion of the management port and loss of Cflowd packets.
If a Layer-2 Cflowd sampling was enabled on a VPLS or Epipe service SAP or SDP and
the ingress traffic that was being sampled was egressing an SDP over a non-Ethernet (e.g.,
PPP, FR) interface, traffic over the service could have been dropped. This issue has been
When upgrading from a release prior to Release 11.0.R5, resource restrictions would have
been enforced. The upgrade of an AA subscriber with an app-profile would have failed if
there was no primary MS-ISA card configured in the AA group. If a node was upgraded
from Release 10.0.R4 and higher to Release 11.0.R1/R2/R3 (which must have been done
by rebooting the entire node), the upgrade would have failed if the obsolete protocol
jajah was configured in AA-subscriber statistics. This issue has been resolved. [161428]
In the unlikely event that a non-Wireless Application Protocol (WAP) UDP packet was
processed as a WAP packet, the MS-ISA would have rebooted. This was only possible
when WAP 1.x was enabled in the application-assurance group. This issue has been
BFD
The system no longer incorrectly sends IPv6 BFD packets marked with a DSCP value of
BE instead of NC1. However, the forwarding class of the packet has always been NC.
[163740-MA]
OAM
The mtrace OAM command now proceeds with a hop-by-hop search if an intermediate
node does not respond to mtrace requests. [151034-MI]
If an ETH-CFM SAA test was started or running continuously and was referencing a MEP
that had not been defined or was operationally down, then changing the administrative
status of the MEP would have caused the CPM/CFM switchover. The workaround was to
shut down the SAA test before changing the administrative status of the MEP. This issue
Cflowd
Application
Assurance
Resolved in 11.0.R4
HW/Platform
The internal data paths on IOM3-XP/IMM cards are now monitored for transmission errors
or for the path to go down and events are generated when such errors are detected:
-
For transmission errors, a tmnxEqCardChipIfCellEvent event will be generated and

the card will be disabled (state failed) if fail-on-error is enabled for that card.
For path down events, a card reset will be triggered with a tmnxEqCardFailure event.
[133973-MI]
267
Resolved Issues
In rare cases for certain compact flash types, DMA read operation timed out trace errors
could have appeared after a node reboot and in some of these cases, the iom.tim file could
have failed to open. This issue has been resolved. [157562, 158744-MI]
The tmnxEqCardPChipCamEvent event did not indicate on which CPM or CFM CAM
errors occurred, printing CPM ? or CFM ?. The associated SNMP trap was formatted
correctly. This issue has been resolved. [159602-MI]
For certain IPv6 routes, show router bgp routes CLI commands failed to match when
only the prefix was specified and the first four (4) bytes of the route address was in a valid
Route Distinguisher (RD) format. This issue has been resolved. [150192-MI]
Compact flash cards formatted as FAT16 were shown incorrectly as FAT32 in the output of
the file dir command. This issue has been resolved. [154228-MI]
The hard-reset-unsupported-mdas functionality (clear card x soft) was not properly

blocked in CLI for some IMM cards. The architecture of these IMM cards prevented 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 could have simply been Soft
Reset (without the need for the hard-reset-unsupported-mdas) but if there was a mandatory
firmware update on these cards, then they must have been hard reset. The cards were:
imm1-40gb-tun, imm5-10gb-xfp, imm1-100gb-cfp, imm12-10gb-sf+, imm3-40gb-qsfp,
imm-1pac-fp3 and imm-2pac-fp3. If the hard-reset-unsupported-mdas keyword was used
when a firmware update was required, then the MDA sections/modules of the IMM would
not have fully booted (as seen under show mda). A hard reset of the IMM could have
been used to bring the card back into service in this case. This issue has been resolved.
[158482-MI]
Some event types were not throttled when throttle was enabled in the log event-control
context. This issue has been resolved. [155997-MI]
In the tmnxHwTable MIB table, the tmnxHwContainedIn value for compact flash disks
now correctly points to the CPM or CFM card that contains these disks. [156465-MI]
Frame Relay
Bundle members of a non frame-relay encapsulation type no longer incorrectly appear in

the tmnxFrIntfTable. [138043-MI]
ATM
The reserved bandwidth on an ATM SAP for an Apipe with a vc-type of VPC might have
been incorrectly displayed as all zeros. This issue has been resolved. [158447-MI]
IPv6
Packets received on an IPv6 VPRN interface that are forwarded to the CPM but not
destined to any local IPv6 address in the base routing instance will no longer cause a
system reset, if GRT leaking is enabled in the VPRN. [160366-MA]
DHCP
When a DHCP server replied with a DHCPNAK upon a client DHCP renew or rebind, the
populated lease-state was correctly removed from the service and the DHCPNAK was
forwarded to the DHCP client. Starting with Release 11.0.R4, in this scenario, the
DHCPRELEASE is no longer incorrectly spoofed to the DHCP server in case the
remaining lease-time was still longer than five (5) minutes. [152359-MI]
CLI
System
268
Resolved Issues
IPsec
OSPF
In Release 11.0.R1, debugging and statistics improvements for ESM deployments were
introduced and many new counters were added in that context. Some of those counters
might have been inaccurate in some specific scenarios. This issue has been resolved.
[154122-MI]
Local DHCP server leases synchronized via MCS could have failed to be populated on the
failover node when persistency was congested. These non-populated DHCP leases would
have had as local delete reason no more free memory in the tools dump redundancy
multi-chassis sync-database detail type local-deleted CLI command output. This issue has
When a DHCP relay was configured with multiple DHCP servers, relay-unicast-msg
release-update-src-ip and gi-address ip-address src-ip-addr, a unicast DHCP Renew
was incorrectly broadcast to all configured DHCP servers instead of being unicast to one of
the DHCP servers as specified by the incoming DHCP packet. This issue has been
IP fragmentation on the private tunnel SAP interface would have caused fragments with IP
header checksum equal to 0xFFFF to be discarded on the terminating ISA Tunnel MS-ISA.
As a workaround for networks with low MTU network links, IP reassembly could have
been configured on the ISA Tunnel group. This issue has been resolved. [159140-MI]
For multi-chassis IPsec (MC-IPsec), it is strongly recommended that the MC-IPsec pair
lifetime be configured to identical values on both of the MC-IPsec nodes and that it is
configured to a much higher value than the IPsec peers lifetime. Breaking these
recommendations could have resulted in the IPsec ISA becoming unresponsive and
resetting upon taking a tech-support file. This issue has been resolved but the above
recommendations still apply. [160740-MI]
Using spf-timers less than 500ms will no longer cause full SPF runs to be delayed for long
periods of time. [159067-MA]
In Releases 10.0 and earlier, BFD could only be enabled on the primary OSPF interface.
The secondary interfaces would follow the behavior of the primary. This meant that if there
was no primary, no BFD was possible on the secondary interfaces.
Starting with Release 11.0.R4, this limitation is removed and BFD now needs to be configured on each individual secondary interface. [160163-MA]
BGP
In cases where the specified OSPF interface MTU caused an LSU (link-state-update) to
require fragmentation, the first LSU fragment did not have the 802.1p priority bits set
correctly (the bits would have always been 000) in the 802.1Q header. If there was a besteffort network-queue on the egress port that was configured to drop low-priority
forwarding-class traffic, these fragments would have always been dropped, and this could
have resulted in a situation where the OSPF neighbor would have become stuck in
loading state. This issue has been resolved. [160776-MI]
In certain scenarios, importing BGP-VPN routes with the same route distinguisher and the
same subnets from both a local and a remote VRF could have caused BGP-VPN routes to
be lost. This issue has been resolved. [157311-MI]
In route policies used for BGP peer-tracking and BGP next-hop resolution, the only
supported match conditions are protocol (and optionally, instance ID for those protocols
269
Resolved Issues
with multiple instances) and prefix-list. If other match conditions are specified in an entry,
they result in a non-match with any considered route. In Release 11.0.R1 to Release
11.0.R3, other match conditions were partially supported. [158225-MI]
LDP
A graceful restart of an LDP peer could have caused an error message LOGGERCRITICAL-tmnxLogTraceError-2002 [A:RTCP:UNUSUAL_ERROR]: Slot A:
rtcp_syncRcvBytesConsumed: fd 0 doesn't map to a socket. This was an innocuous error
that should have been ignored. This issue has been resolved. [146194-MI]
QoS
Traffic throughput on LAG-based SAP queues might have been lower than expected when
WRED-queue policies were used on those queues. This issue has been resolved. [156286MI]
In some cases, ports could not be removed from a LAG if that LAG contained subscriber
SAPs with egress policers and the LAG had one (1) or more ports on both IOM2-20g and
IOM3-XP/IMM cards. A workaround was to ensure that the primary port in the LAG was
always on the IOM2-20g. This issue has been resolved. [159077-MA]
A received VCCV-ping packet with unsupported TLVs might have resulted in an active
CPM/CFM reset. This issue has been resolved. [151101-MA]
It was possible, although it should not have been, to destroy a non-learned VPLS FDB
MAC address via the SNMP OID tlsFdbRowStatus. Removing the VRRP Master MAC
address 00:00:5e:xx:xx:xx in an R-VPLS via this method could have led to service
impact. This action was correctly blocked in CLI when using the command clear service
id service-id fdb mac 00:00:5e:xx:xx:xx and resulted in an error message Cannot
perform clear operation - Entry is not of learned type. This issue has been resolved.
[160710-MI]
BGP peering flapped continuously when the route reflector received a BGP-VPWS update
with multiple NLRIs in the same update due to incorrect processing of CSV TLV. This
issue has been resolved. [160335]
A BGP-VPWS update received with an unreachable NLRI(s) was not processed when the
CSV TLV was not present. This issue has been resolved and a BGP-VPWS unreachable
NLRI without a CSV TLV is now accepted. [161493]
The relay-plain-bootp configuration enabled the relaying of plain BOOTP packets but
BOOTP packets without magic cookie or end option (255) present were dropped, even
though RFC 1533 did not state these options had to be present. This issue has been
If there was a PPPoE session with a session-timeout, the session-timeout was incorrectly
incremented with the uptime of the session in the following cases:
Services General
Subscriber
Management
270
after a DHCP renewal ACK
after a CoA with no Session-Timeout attribute included
after a tools perform subscriber-mgmt edit ppp-session
after LUDB entry change (only for LUDB authenticated sessions). [159472-MA]
Resolved Issues
BGP Multi-homing
A rebooting BGP-MH node might, at times, have sent its own NLRI without any faults
before hearing from other active designated forwarder(s) (DF) in the network. This could
have resulted in the current DF transitioning to non DF immediately and thereby causing
traffic loss until the expiration of boot timer. The DF election is no longer ran before the
boot-timer expires, the site-activation-timer expires, or another peer transitions from DF to
non-DF while the site-activation-timer is running. This issue has been resolved. [151406MA]
Application
Assurance
A benign FpMain:CHILE:dpiSessionRemoveFlowFromHash trace message might have

occurred during a rare traffic scenario requiring duplicate protocol control packets with
specific packet timings and unidirectional data packets. This issue has been resolved.
[160094-MI]
Per-partition statistic values greater than 232 were displayed incorrectly in the output of the
CLI show commands for protocol, application and app-group. The protocol, application
and app-group count detail option could have been used to properly display CLI statistics
for values greater than 232. This issue has been resolved. [160586-MI]
BFD
BFD packets are no longer subject to the configurable protocol-protection feature. Multihop BFD packets are not bound to a specific interface and hence, protocol-protection is not
applicable. For single-hop BFD, the incoming BFD packets have their interface verified on
the line card, which prevents single-hop BFD packets from arriving on the wrong interface.
[158927-MI]
NAT
SNMP trap notification tmnxNatLsnSubTcpPortUsageHigh was incorrectly missing

objects tmnxNatNotifyInsideVRtrID, tmnxNatNotifyInsideAddrType and
tmnxNatNotifyInsideAddr specified in the TIMETRA-NAT-MIB. This issue has been
In case of NAT inter-chassis redundancy, the local check for presence of the monitored
prefixes in the route-table could have failed causing both NAT outside pools to have been
incorrectly marked as active. The root cause was a change of protocol (e.g., OSPF to IS-IS)
that populated the monitored prefix in the route-table. This issue has been resolved. If this
issue was present when running a older software version, service could have been restored
by removing and re-adding the monitored prefixes configuration and making sure the
preferred protocol remained the same from that point onward. [159881-MA]
PTP
If ptp-hw-assist was configured on an Ethernet port that negotiated to 100 Mbps or 10

Mbps speed, time synchronization between the 7750 SR/7450 ESS and other PTP clocks
might have been inaccurate. This issue has been resolved. [155147-MI]
Wifi Offload and

Aggregation
If a received Restart counter value in an Echo Response or GTP-C message is lower than
the recorded Restart counter value and the difference is less than six (6), then the WLANGW will no longer clear the sessions for the peer, considering this is a race condition as per
3GPP 23.007 section 18. The rollover of the counter is taken into account when computing
the difference. [159272-MI]
271
Resolved Issues
OAM
IP addresses from a NAT pool are distributed over the different MS-ISAs in a wlan-gwgroup. Sufficient IP addresses must be configured so that at least every MS-ISA has an IP
address assigned, or else service or traffic impact is possible. An alarm and trap have been
added to warn the operator in case such configuration is present. Previously, if not enough
IP addresses were configured for a pool of type wlan-gw-anchor, the MS-ISA card without
an IP address assigned might have reset when a UE connected. This issue has been
resolved. [159930, 160089-MI]
Sending one space or a string of spaces in an SSH session could have caused the active
CPM or CFM to reset. This issue has been resolved. [159718-MA]
Resolved in 11.0.R3
HW/Platform
CLI
272
New firmware for the imm1-100gb-cfp and imm12-10gb-sf+ cards introduces various
improvements. This firmware upgrade is mandatory and a Soft Reset is not allowed during
an ISSU from an image prior to Release 10.0.R11 to the 10.0.R11 image or later (Hard
Reset must be used instead). A Deferred MDA Reset is not supported in this case (Hard
Reset is mandatory). [132450, 134432-MI]
Certain transient hardware failures of the switch fabric interface on imm3-40gb-qsfp,

imm12-10gb-sf+ and imm1-100gb-cfp cards could, in rare cases, have resulted in traffic
loss on these cards. This type of transient hardware failure will now trigger an IMM reset to
automatically recover from this condition. [154300-MA]
In very rare cases, the network processor on FP2- or FP3-based line cards stopped
forwarding packets due to a transient hardware condition. This type of transient hardware
failure will now trigger a card reset to automatically recover from this condition. [154898MI]
The * now correctly appears in the prompt, indicating a configuration change when the
administrative state of an MPLS or RSVP interface is changed. [138887-MI]
The show router route-table all command did not display aggregate routes. This was only
an issue when the optional parameter all was used. This issue has been resolved.
[153621-MI]
The configure router mpls-labels static-labels command is now supported. [154604-MI]
Executing a cron job would have caused the * to appear in the CLI prompt even if the cron
job did not generate a change in the configuration (e.g., show commands, OAM SAA, etc).
When multiple IPv6 CPM-filter entries had an ip-prefix-list applied, the show filter
match-list ip-prefix-list command incorrectly displayed only a single referenced IPv6
CPM-filter entry. This issue has been resolved. [157329-MI]
Resolved Issues
System
When the CPMs/CFMs BITS output port was enabled and the BITS output port selection
was set to internal-clock, phase transients on the transmitted clock from the standby
CPM/CFM might have occurred when the standby CPMs/CFM's central clock switched
between timing references. This issue has been resolved. [156791-MI]
Filter Policies
If the system-wide filter log binding limit was exceeded by adding a filter log for an
inactive IP or IPv6 filter entry that had RADIUS-shared filter copies, then the standby
CPM/CFM might have become unstable. This issue has been resolved. [156078-MA]
IP Multicast
Multicast traffic forwarding delay upon receiving an IGMP join on a VPLS with IGMP
snooping enabled could have increased for a few seconds at every accounting collection
interval. This would have only occurred if accounting was enabled and counters were
collected for a scaled number of SAPs on the same IOM/IMM/XCM as the egress SAP(s)
of the multicast traffic. The effect of accounting collection on multicast forwarding delay
has been reduced. [153697-MI]
Routing
In very rare cases, an IOM/XCM could have reset while the FIB was being updated with a
large number of IPv6 routes. This issue has been resolved. [156377-MI]
QoS
Network ingress traffic will now be redirected to a policer, based on the queue-groupredirect configuration when the FC mapping is done by QPPB. [157414-MI]
OSPF
Enabling suppress-dn-bit option will now clear the DN-bit for type 3 LSAs until the next
LSA refresh. [154272-MI]
BGP
When a BGP peer was applicable to peer-tracking, it could have taken up to 30 minutes
before a disconnected peer was automatically re-established; however, it could have been
manually re-established at any time. This issue has been resolved. [155789-MI]
Services General
A GRE/IP-in-IP tunnel with a lower destination IP address than the previous tunnel (lower
index number) was not synchronized to the standby CPM/CFM. As a result, performing a
High-Availability switchover would have brought the affected tunnel down and would have
removed the destination IP address from the configuration. This issue has been resolved.
[155556-MA]
The source MAC address of an unknown unicast frame, received on an R-VPLS endpoint
and rerouted (i.e., due to proxy ARP enabled on the R-VPLS interface) out of the R-VPLS,
would not have been learned. This could have happened in case the R-VPLS FDB was
cleared, but the R-VPLS interface ARP table was maintained. In this case, the FDB was
updated correctly when the interface ARP entry was refreshed. This issue has been
VPRN and IES interfaces should not have referred to VPLS services auto-created using
vpls-group. This issue has been resolved. [156641-MI]
273
Resolved Issues
IPv6 HTTP-redirect now works correctly on a non-group interface of an IES or VPRN

service. This was not an issue on Layer-2 services and group interfaces, and has now been
In cases where only PPP Force IPv6CP and no other DHCPv6 attributes were returned
from RADIUS for a certain PPPoE-v6 host, the host was synchronized via MCS from the
master SRRP node but would have failed the installation on the standby SRRP node. A
workaround was to ensure that RADIUS returned at least one other DHCPv6 attribute. This
Successful PPPoE connects/disconnects by a subscriber host were incorrectly being

counted as failed connect attempts for the host-lockout function. This was only an issue in
Release 11.0.R1 and 11.0.R2, and has now been resolved. [158593-MI]
MLPPP
When an MLPPPoX bundle terminated on LNS containing multiple PPP links, some outof-order MLPPP fragments for the bundle (but per link in order) might have been dropped.
VRRP
Changing the VR-MAC on the standby VRRP router will now immediately update the
standby VRRP router's ARP table. [157441-MI]
L2TP
LAC devices that did not include AVP InitialRxLcpConfReq in the Incoming-CallConnected (ICCN) message would have failed setup with 7750 SR LNS with this error
message: restarting LCP: no initial RX confReq. This issue has been resolved. [156687MI]
NAT
Port-forwarding limits were not verified for L2-aware port forwards recovered from a
persistency file. If the configured nat-policy limit was changed before persistency file
recovery, BB_MGMT:natMgmtSubscrPF max. nr. of PFs exceeded for subscr traps
might have been generated. This issue has been resolved. [154023-MI]
WiFi Offload and

Aggregation
Downstream subscriber traffic fragments could have been corrupted by the WLAN-GW
MS-ISA so the host was not able to reassemble the packets. Also, if tcp-mss-adjust was
enabled, the MS-ISA card might have reset. This issue has been resolved. [157744,
157802-MA]
Subscriber
Management
Resolved in 11.0.R2
CLI
274
Starting with Release 11.0.R2, the SNMP attribute descriptions for SFP or XFP labels will
be changed to SFF (Small Form Factor). The SFF label will represent all of the small form
Resolved Issues
factor pluggable optics: SFP, SFP+, XFP, QSFP+, CFP and CXP. The TIMETRA-PORTMIB has been updated with an example of the changes. [147748-MI]
Textual names for filters and policies are now displayed in the related show commands.
[154222-MI]
Under certain conditions, a change in the system timing reference selected by the active
CPM could have caused an unnecessary phase transient on the BITS output of the standby
CPM. This issue has been resolved. [151721-MI]
In certain instances, the SyncE Synchronization Status Message (SSM) quality level was
not sent in the SSM bit position configured in CLI. This issue has been resolved.
[155055-MI]
In Release 11.0.R1, the support.tim image file was introduced and is required for all 7450
ESS, 7750 SR, 7950 XRS and 7710 SR platforms. When running Release 11.0.R1, if the
BOF was configured to point the secondary-image or tertiary-image to a pre-Release
11.0.R1 set of image files (e.g., 10.0.Rn) on a local compact flash, then redundancy
synchronization would have failed when ran explicitly (e.g., admin redundancy
synchronize boot-env) or when automatic synchronization executed (e.g., as the result of
admin save when configure redundancy synchronize boot-env is configured). A
workaround was to place a dummy support.tim file in the directory referenced by the
secondary-image or tertiary-image. This issue has been resolved. [155059-MA]
Starting an SSH session to a remote SSH server could, in very rare cases, have resulted in
an unexpected active CPM/CFM reset. This issue has been resolved. [155124-MI]
LAG
When adding/removing the first/last member to/from a LAG and that LAG was in use by a
Mirror-Dest SAP(s), Egress ACL/QoS entry resources might have failed to be allocated
properly. This issue has been resolved. [154924-MI]
MLPPP
For MLPPP subscribers on LNS, MLPPP fragments egressing the MS-ISA running the
ISA-BB application did not preserve the Forwarding Class marking of the incoming IP
packet. This issue has been resolved. [154647-MI]
OSPF
Configuring advertise-tunnel under OSPF before disabling RSVP-shortcut could have

resulted in an active CPM/CFM reset. The workaround was to disable RSVP-shortcut first.
IS-IS
The node count in the show router isis spf-log CLI command output was incorrect for ISIS LFA SPF entries. This was only a display issue and had no operational impact. This
An SR OS node acting as a Graceful Restart (GR) helper stopped advertising the neighbor
in its IS-IS LSP after the neighboring node had either requested a GR with Suppress
Advertisement set, or had Suppress Advertisement set after booting in overload state.
[155198-MA]
System
275
Resolved Issues
BGP
MPLS/RSVP
LDP
IP Multicast
276
A peer-tracking policy might not been honored when a peer in disabled state because of
peer-tracking was disabled/enabled, followed by a CPM/CFM switchover. The
workaround was to disable or enable peer-tracking or the peer-tracking policy, or to toggle
the BGP administrative state at the neighbor, group, or BGP level. This issue has been
Peer-tracking policy was not honored when a disabled peer was cleared using the clear
router bgp protocol/neighbor command. The workaround was to disable and enable
enable-peer-tracking or peer-tracking-policy, or to toggle BGP (shutdown/no
shutdown). This issue has been resolved. [154404-MI]
When enable-rr-vpn-forwarding was enabled, traffic to local VPRN routes advertised by

BGP peers that had advertise-label set might have been dropped. This issue has been
When a configuration was saved using admin save detail and the configuration included
a VPRN that was participating in a BGP confederation, execution of the configuration file
failed due to mutual exclusivity with certain grt-lookup default commands. This issue has
When a subroutine used in a policy contained other defined items such as AS-path, ASpath-group, community or prefix-list, the routes were not re-evaluated if one of these lower
items was adapted while the policy was in use. The issue was unnoticeable if the applicable
policy or subroutine was touched/changed, as this would have triggered the re-evaluation.
Roll back was not supported when the configure router mpls-labels static-labels max-lsplabels max-lsp-label max-svc-labels max-svc-label command was used to set custom label
range. This issue has been resolved. [153695-MI]
When an LSP was configured between ABR nodes connected to the transit area of an
OSPF virtual link, CSPF computed and signaled an inter-area LSP path using the transit
area TE links when the destination of the LSP was the router-id and the latter was part of an
area other than the transit area. In Release 11.0.R2, CSPF computes and signals an intraarea LSP path using the transit area TE links regardless if the destination router-id is part of
Area 0, the transit area, or any other area. [154586-MI]
When exceeding the NHLFE limit, LDP shut down and could have ended up in a state
where it could not be recovered by the CLI command shutdown/no shutdown, reporting
INFO: LDP #1146 LDP cleanup must complete before no shutdown - Cleanup in
progress. The workaround was to perform a CPM/CFM switchover or if no standby
CPM/CFM was installed, to reboot the node. This issue has been resolved. [131204-MA]
LDP per interface multicast-traffic disable configuration was broken, causing multicast
traffic not to be disabled on the interface. This issue has been resolved. [154614-MI]
When max-num-sources was configured in IGMP-snooping (under sap/mesh-sdp/spokesdp), in the IGMP-policy for multi-chassis ESM, or on an L3 IGMP interface, it was not
counted per group for static groups, which meant that when one group had reached the
maximum number of sources, no additional sources would have been allowed on other
groups, even though they had not yet reached the maximum. This issue has been resolved.
[154383-MI]
Resolved Issues
Combined ASBR and PE function was not supported for the inter-AS mVPN function. If a
node was acting as an ASBR for the inter-AS mVPN function, there could have been no
mVPNs configured on the ASBR that participated in the inter-AS MDTs over this ASBR.
On a node with PIM using spoke-SDP-based outgoing interfaces or with PIM enabled in an
mVPN, if a line card was provisioned after PIM was configured on the node, multicast
traffic might not have gotten forwarded on ports that were located on the newly
provisioned line card. The workaround was to reboot the standby CPM, followed by a
CPM switchover after the new line card(s) had been provisioned. This issue has been
Using the tools perform cron tod re-evaluate filter ipv6-filter ipv6_filter_id command (or
the equivalent SNMP command) no longer causes an active CPM/CFM reset. [154196-MI]
When a subpolicy was deleted, the parent policies and consequently the users of the parent
policies were not being notified of the change. This was also not being reflected in the
output of show router policy-edits. This issue has been resolved. [154387-MI]
The reachability status of redirect-policy destinations via the ping-test was no longer
updated after a CPM/CFM switchover. A toggling (shutdown/no shutdown) of the redirectpolicy was required to resume the updates of the reachability status. This issue has been
Services General
If a login to a CLI session is attempted via SSH or telnet and access console permission
is not configured for the user, then SR OS will no longer request a password multiple times
and will instead immediately close the connection after authentication. [127235, 154833MI]
Subscriber
Management
For IP-only static hosts, packet loss could have occurred if the packet was sent immediately
after the ARP exchange. This issue has been resolved. [154132-MI]
When arp-populate was enabled on a group-interface and an IPoEv4 unnumbered

subscriber-host was installed below this group interface, the ARP cache would have been
cleared after a High-Availability CPM/CFM switchover. This would have resulted in
downstream traffic loss until the ARP cache was populated again. This issue has been
The registration of a DHCPv4 server in a VRF context was not done correctly if a DHCPv6
server name was present that had a name that was alphabetically lower than the DHCPv4
server name. This resulted in the DHCPv4 server not responding after a CPM/CFM
switchover. This issue has been resolved. [155003-MI]
When a selectable tunnel was reinserted in the LAC tunnel-selection-blacklist, then it

would not have gone back to selectable blacklist-state when the blacklist timer expired. It
remained blacklisted until no alternative tunnels were available for selection and it was
forced to be tried again, or until it was purged from the blacklist (either explicitly by an
operator clear command or implicitly as the result of reducing the blacklist list-length), or
until a new blacklist timer was started (when a new peer or tunnel was added or when the
blacklist max-time was changed). This issue has been resolved. [155036-MI]
PIM
Filter Policies
277
Resolved Issues
WiFi Offload and

Aggregation
VPRN/2547
278
An invalid or unreachable mcast-reporting-dest dest-ip-addr could have resulted in a

memory leak that eventually impacted service or protocols and then resulted in a
CPM/CFM switchover. This issue has been resolved. [155793-MA]
SAP ingress QoS selection criteria, filters and statistics collection could have stopped
working for a few subscribers on first and second generation (FP1-based) line cards and
chassis types. This issue has been resolved. [156188-MA]
For non-migrant data-triggered-ue-creation, the DHCP configuration node in the soft-gre

context should have been empty. Migrant-users DHCP shutdown was not enough. This
WLAN-GW GTP packet debug no longer incorrectly displays QoS values not matching
actual transmitted or received values. [153829-MI]
Multiple isa-radius-policies were not allowed to have overlapping source-address-range IP

addresses while it was not blocked by CLI or SNMP. This issue has been resolved.
[154114-MI]
The AAA isa-radius policy show command source address end might have been
displayed incorrectly. This issue has been resolved. [154269-MI]
For migrant users, the $URL parameter passed to the redirect-URL could have been
misformatted when the UE sent its HTTP headers in multiple TCP segments. This issue has
For migrant users, Web-Redirect always redirected the traffic for the configured destination
port, even when the traffic should have hit a valid forward-entry. A workaround was to
provide a portal server and corresponding server entry on another port (e.g., port 8080).
Web-Redirect in combination with WiFI offload was not supported in Release 11.0.R1.
Still, enabling Web-Redirect might have resulted in loss of all traffic on the MS-ISA until a
reboot of the MS-ISA was performed. This issue has been resolved. [155047-MI]
For migrant users, host promotion and WLAN-GW MS-ISA debug required WLAN-GWgroup configuration to be present in the base-router context. This issue has been resolved.
[155293-MI]
Prior to Release 11.0.R2, the MS-ISDN field part of a create-pdp-context-request message

generated by the WLAN-GW was always filled with leading 0xF values until a fixed value
of 16 digits was reached. In order to interoperate with other vendors and since this is
vaguely defined in 3GPP TS 29.002, starting from Release 11.0.R2, at most one leading
0xF is added (only when there is an odd number of digits). [155977-MI]
When the same VPN routes were received from two (2) different peers having the same
next-hop but different route distinguishers, there was a possibility that another same VPN
route received on one of those peers with a different next-hop but equal route distinguisher
was not imported into the vrf-table if ECMP was not yet reached. This issue has been
Any change in policy that was applicable to all of the configured mVPN VPRNs was not
evaluated dynamically for mvpn-ipv6 routes. It was necessary to toggle the state of BGP
(shutdown/no shutdown) for the policy change to take effect. This issue has been resolved.
[154783-MI]
Resolved Issues
VRRP/SRRP
After a CPM/CFM switchover, VRRP and SRRP instances that relied on a BFD session
would have had the incorrect information that the BFD session had not been configured.
With the BFD session being treated as invalid, the backup VRRP instance would have
become master for a brief period of time until the next Advertisement message was
received from the higher-priority master. This issue has been resolved. [154305-MI]
NAT
With more than one (1) MS-ISA are active in a NAT-group, a ping (or a telnet session)
originated from the CPM and that went through the NAT (using this specific NAT-group)
might have caused system instability. This issue has been resolved. [151733-MA]
If a port-forward could not have been installed on an MS-ISA due to the lack of port
resources, and the system persistence nat-port-forwarding was enabled, the control plane
might have become unstable. This issue has been resolved. [153567-MA]
When configuring the NAT64-node with SNMP, the router could have reached an
inconsistent state in that area. There were two known side-effects of this inconsistent state:
-
The info command inside the nat64-node would have shown the default prefix
when it should not have been shown. This was innocuous, only inconsistent with the
default CLI behavior.
When performing no prefix, a MINOR is shown: MINOR: BB #1120 Invalid prefix

length. Allowed values are [32, 40, 48, 56, 64, 96].
A workaround was to set the destination prefix to the default value by specifying config>router>nat>inside>nat64# prefix 64:ff9b::/96. To get to a consistent state, the NAT64node had to be removed (via CLI or SNMP) and recreated (only via CLI). This issue has
PTP
If SNMP was used, NAT inside node was incorrectly allowed to be removed if there was
still a reference pointing to RADIUS proxy server in subscriber identification node. This
PTP would not have synchronized time properly to a master clock if the master clock was
reached through an interface with a null SAP (x/y/z:0) with ptp-hw-assist configured. PTP
timing packets received on this null SAP would not have been properly timestamped at the
port, but would have been timestamped at the CPM/CFM card instead. PTP timing packets
transmitted over this null SAP would have been correctly timestamped at the port. Because
the timestamp reference point in the transmitted packets was different from that in the
received packets, there might have been an error in the calculation of time offset between
the local clock and the master clock. This time error might have been several
microseconds. This issue has been resolved. [154195-MI]
If ptp-hw-assist was configured on an Ethernet port that had the dot1q-etype configured
away from the default value of 0x8100, PTP timing packets would not have been properly
timestamped at the port. Received PTP timing packets on the interface would have been
timestamped at the CPM/CFM, instead of being timestamped at the port. Transmitted PTP
timing packets would have had timing information corrupted. Starting in Release 11.0.R2,
it is only possible to configure ptp-hw-assist on Ethernet interfaces that have the dot1qetype configured at the default value of 0x8100. [154218-MI]
279
Resolved Issues
If ptp-hw-assist was configured on an Ethernet port with null encapsulation and the port
was later changed to dot1q encapsulation, the operator must hard reset (clear) the
MDA/CMA to have had received PTP packets properly timestamped at the port.
If the MDA/CMA was not cleared, transmitted packets would have been correctly timestamped at the port, but received packets would have been incorrectly timestamped at the
CPM/CFM. Because the timestamp reference point was different in the transmitted and
received packets, this led to an error in the calculation of time offset between the local
clock and the master clock. This time error might have been several microseconds. This
If more than one PTP timing packet flow was received from the same source IP address,
then both flows might have been viewed as a single flow from the parent clock. The 1588
time and frequency recovery would have been unable to use this combined packet flow to
synchronize the local clock with the chosen parent clock.
This condition might have been encountered if the parent clock used static configuration
for slave clocks. This issue has been resolved. [155051-MI]
BFD
Application
Assurance
The 7750 SR-c4 might not have remained synchronized in time with the parent PTP clock.
It would initially synchronize properly with the parent clock, and if the 7750 SR-c4
remained frequency-locked to a primary-reference-traceable frequency reference (e.g.,
synchronous Ethernet, BITS), PTP would remain synchronized in time with the parent PTP
clock. However, if the frequency reference was lost for a period of time, PTP time might
have drifted during this period, and the 7750 SR-c4 might have lost synchronization with
the parent clock. This issue has been resolved. [155654-MI]
After a CPM/CFM switchover, it was possible for operators to incorrectly remove the BFD
configuration from a network interface even if the interface had BFD enabled under OSPF.
This resulted in an invalid configuration that was not executable after a reboot. This issue
A BFD down event caused by missed BFD PDUs was incorrectly reported as a
linkDown event for BFD-enabled RSVP interfaces. This issue has been resolved.
[153390-MI]
The MS-ISA cards configured in an AA group might have rebooted if partition 0 was
configured via SNMP for that group. Partition 0 is an invalid partition and is blocked via
CLI. This issue has been resolved. [155337-MA]
When setting the value of tmnxBsxCflowdPerfExpRateNum via SNMP, a value outside of

the allowable range of [1-2] might have caused the active CPM/CFM to reboot. This issue
Resolved in 11.0.R1
HW/Platform
280
When starting with an active CPM/CFM with sync-if-timing state of Master Free Run, a
CPM/CFM High-Availability switchover will now correctly show a new state of Master
Resolved Issues
Holdover. However, when switching back to the original CPM/CFM, the state incorrectly
continues to show Master Holdover rather than Master Free Run. This issue has been
The system was enhanced for IOM3-XPs, IMMs and XCMs to recover automatically from
memory errors on the switch fabric interface, and for IOMs/IMMs/XCMs to reset if the
memory defect is not recoverable. These errors were very rare. [96172-MA]
In case of an m20-1gb-xp-tx MDA or imm48-1gb-tx card, egress port forwarding could

have stopped when the far-end port changed speeds without bringing down the link, which
was normally common practice. Bouncing the port would bring the port out of that bad
state and the issue could be mitigated by configuring port ethernet autonegotiate limited
and setting a fixed speed the far-end port supports. This issue has been resolved. [129129MA]
The firmware for the c1-1gb-xp-sfp CMA has been updated to address a rare problem
where the CMA failed to achieve a valid communications link with the forwarding plane.
[132006-MI]
The firmware for the p1-100g-cfp MDA has been updated with various improvements,
including more consistent PCS alarming and proper operation of port LEDs during MDA
reset. [132448-MA]
Upgrading from Release 10.0.R3 or earlier to Release 10.0.R4 or later will auto-upgrade
the CPM/CFM firmware for card types: sfm3-12, sfm4-12, cfm-xp and cfm-c4-xp. Ensure
the upgrade procedures are followed for the automatic firmware upgrade to take effect. The
firmware will be automatically upgraded upon CPM/CFM reboot and initial boot time will
be several minutes longer for firmware programming. The firmware upgrade addresses the
issue where runt frames entering the Ethernet management port (out of band) would slow
down the connection, and the issue where the management port bounces when in half
duplex. [134420-MI]
When a CCM was reseated, all LEDs except CF3 remained off for the standby CFM. A
workaround was to press the ACO button after the card had been reseated. This issue has
The system might not have recognized a specific type of 1-GigE SFPs (Part#:
3HE01389CAAA01) if they were inserted into ports on the m20-1gb-xp-sfp or m10-1gbxp-sfp MDAs. This issue has been resolved. [135727-MI]
There was inconsistent behavior of no frame lock alarm generation for the following
types of MDAs: m1-10gb-xp-xfp, m2-10gb-xp-xfp, m4-10gb-xp-xfp, imm2-10gb-xp-xfp,
imm4-10gb-xp-xfp, imm5-10gb-xp-xfp, icm2-10gb-xp-xfp. This issue has been resolved.
[138442-MI]
The following issues of the 7950 XRS-20 are resolved:

-
The clear SFM command now applies to XRS-20 SFMs.
An amber LED on an SFM now indicates that the SFM is operationally down.
The admin reboot command now power-cycles the XRS-20 SFMs.
When the active CPM boots, it will power-cycle the XRS-20 SFMs.
Note: When a chassis is powered up, the APEQs automatically turn on power to the SFMs,
but the active CPM will power-cycle them. [139940-MI]
281
Resolved Issues
The following issues of the 7750 SR-12e are resolved:

-
The clear SFM command now applies to the mini SFMs on SR-12e. The command
fails on the CPM-collocated SFMs in SR-12e (#1 and #4).
An amber LED on an SFM now indicates that the SFM is operationally down.
The admin reboot command now power-cycles the mini SFMs on SR-12e.
When the active CPM boots, it will power-cycle the mini SFMs on SR-12e.
Note: When a chassis is powered up, the Advanced Power EQualization and control modules (APEQs) automatically turn on power to the SFMs, but the active CPM will powercycle them. [139940-MI]
282
A 7450 ESS-7/12 or 7750 SR-7/12 chassis operating with a single CPM4/SFM4 might
have experienced a slight loss of bandwidth to a card in slot 1. This issue has been resolved.
[141638-MI]
On systems with two timing references and when the preferred and selected reference input
experienced a failure (i.e., AIS-L), the system might have gone into Holdover state (i.e.,
Master Holdover) for a few seconds before changing to the correct Master Locked state.
When an IOM/XCM was disabled due to multiple failures, an IOM/XCM-failed alarm was
raised, but it did not appear in the show system alarms command output. This issue has
The management of the 7950 XRS-20 APEQs is now fully operational. [142750-MA]
In very rare cases, a reset of both CPMs might have occurred when, due to a hardware
condition, communication was lost between the active and standby CPM. This issue has
CLI WAN port group restrictions have now been aligned with the port groups in the
underlying hardware for the cx20-10g-sfp. The grouping prior to Release 10.0.R5 was:
1..4, 5..8, 9..12, 13..16, 17..20. In Release 10.0.R5 and higher, the new grouping is as
follows: 1..4, 5..8, 9..10, 11..14, 15..18, 19..20. Configuration files from Release 10.0.R4
will need to be adjusted accordingly. [144163-MI]
Alarm reporting for all 10GE Ethernet ports now have enhanced detection and squelching
of spurious alarms in Release 10.0.R5. Previously, some types of alarms where noisy when
configured for WAN mode or when an optic was physically removed from an MDA.
[144343-MI]
When performing a CFM High-Availability switchover on a 7750 SR-c12 while EFMOAM was configured with very short timers (e.g., transmit-interval x multiplier < 2
seconds), it was possible for EFM to bounce due to its messages not being transmitted
during the switchover. This issue has been resolved. [146407-MI]
IOMs/IMMs/XCMs will no longer reset when a user logs out of an out-of-band telnet
session in case the source IP address of the telnet session is reachable via both in-band and
out-of-band. This issue affected only out-of-band telnet sessions and not SSH sessions.
[146701-MA]
On the 7750 SR-12e, the LEDs on the standby CPM for the fan and power supplies are now
off. The standby CPM does not monitor the state of either the fans or the power supplies of
a system. [147699-MI]
The "show system alarms" CLI command now only displays alarms for resources that are
administratively enabled (no shutdown). [148181-MI]
Resolved Issues
In very rare cases, data corruption introduced by a bad line card could have propagated to
the CPM and caused a crash. The CPM is now prevented from using corrupted data to
avoid the crash. [149944-MA]
Some SFM2-80G CPMs in 7450 ESS-6/6v that had been equipped with 1GB DIMMs
could have become unstable after the system had been upgraded to Release 8.0.R1 or any
other later release up to and including Release 11.0.R1 by means of the admin reboot
upgrade command. The workaround was to never use admin reboot upgrade on a 7450
ESS-6/6v. [152546-MA]
In some cases, line cards that were powered down due to not having enough available
APEQ power or cards with hardware defects that failed when fail-on-error had been
enabled resulted in system instability if the line card had one (1) or more LAG ports
configured. The workaround was to make sure that enough APEQs were always available
and to disable the fail-on-error option. [152790-MI]
RADIUS
If RADIUS authentication for servers was set to coa-only and the secret was greater than
20 characters, then authentication would fail. This issue has been resolved. [149442-MI]
CLI
The oam mac-purge CLI command now has a new force option. When force is
specified, the specified FIB entry will purged even if it was created by another node.
[88992-MI]
When mixed-mode was enabled on the 7450 ESS-6/6v chassis, it was possible to configure
L2TP even though the protocol was not supported on the platform. No L2TP configuration
can be entered under either the Base router or any VPRN, and the L2TP configuration node
has been removed. [134318-MI]
The http-download command is not supported and has been removed from the CLI.
[134433-MI]
The clear li CLI command was missing as a denied action in the system security profiles
default and administrative. Entries could be added manually in the profiles. This issue
All memory is now returned to the system after CLI command output is redirected to a
match filter that uses regular expressions. [139474-MI]
If multiple vi editors were open and if one of the sessions waited for input yank buffer
exceeded: press <y> to delete anyways by using vi command d1G, a High-Availability
switchover might have occurred. This issue has been resolved. [139785-MA]
The output of the tools dump service base-stats CLI command is now formatted and
displayed correctly. Previously, the newline characters had been missing and the columns
were not aligned. [140543-MI]
Changing the active address in the BOF caused the asterisk '*' to appear in the CLI prompt.
The asterisk did not disappear when executing "bof save". An "admin save" was also
required for the asterisk to disappear. This issue has been resolved. [141527-MI]
An asterisk (*) indicating a configuration change no longer appears at the CLI prompt after
an L2TP session is established or deleted. [142124-MI]
The template-refresh-timeout parameter of an IPFIX collector did not support a value of

"hrs 24". This issue has been resolved. [142712-MI]
283
Resolved Issues
System
284
When using the TACACS+ server for authorization and issuing commands using /, the
command would be authorized even if it was not allowed due to the fact that the command
sent to the TACACS+ server for authorization also contained the context from which it was
executed and not only the command that followed /. This issue has been resolved.
[145112-MI]
When overriding the CIR of an MSS scheduler in CLI, a CIR override of max would be
changed to zero (0). This included executing the config file during bootup. This issue has
An entry in the output of show system lldp neighbor will no longer incorrectly show the
system name with additional characters if the system name of the previous entry is longer.
[148185-MI]
When there was a RADIUS-authenticated user logged in with multiple TiMetra-Profile

VSAs that had the exact same value, a node could have become blocked for all user access
after executing the show system security user user-name detail CLI command. This issue
When the configure system snmp shutdown/no shutdown command was issued, the *
would not appear in the prompt reflecting a CLI change that was not saved. This issue has
The description field was missing under the show router nat pool and show service nat
policy commands. This issue has been resolved. [149526-MI]
Opening a file in the vi editor, pressing shift-R, and pasting a lot of text into the terminal
window no longer results in an active CPM/CFM reset. [152247-MI]
The SSHClientHostFile was incorrectly not copied from the compact flash of the active
CPM/CFM to the standby CPM/CFM after an admin redundancy synchronize command
was executed. This could have resulted in a loss of SSH client host keys if the previous
active CPM/CFM came up as active CPM/CFM after a node reboot. The workaround was
to copy the file manually. This issue has been resolved. [152994-MI]
Internal communication failure between the active CPM and a line card due to a hardware
defect might have resulted in a wider system instability. This issue has been resolved.
[83344-MA]
The Ethernet management port on the CPM/CFM might have gone operationally down and
stayed down until a CPM/CFM switchover. This only occurred when the Ethernet
management port was in half-duplex mode. A workaround was to have the Ethernet
management port operate in full-duplex mode. This issue has been resolved. [122596-MA]
When using ssh preserve-key, the SSH key files were not synchronized with the admin
redundancy synchronize boot-env CLI command. A workaround to synchronize the SSH
key files was to use the admin redundancy synchronize config CLI command. This issue
When negative threshold values were configured for alarms and the last value sampled was
negative, the values were not properly displayed in show system thresholds. This issue
On rare occasions, retrieving a routing interfaces statistics while the system was in the
process of deleting that interface might have resulted in a CPM/CFM High-Availability
switchover. This issue has been resolved. [136779-MI]
Resolved Issues
If protocol-protection was enabled and OSPF was configured on an R-VPLS interface,

incoming OSPF packets from a VPLS SDP binding were dropped unless OSPF was also
enabled on the incoming network interface. The workaround was to either disable protocolprotection or to enable OSPF on all network interfaces when OSPF was configured on an
R-VPLS interface. This issue has been resolved. [137504-MI]
The tmnxChassisNotificationClear event log did not contain the unit number of the PEM
whose alarm was cleared. This issue has been resolved. [138188-MI]
The * will now appear in the prompt indicating a configuration change when the
administrative state of an MCM is changed. [138911-MI]
The debug subscriber-mgmt authentication configuration is now included when debug

configuration is saved with the admin debug-save command. [139194-MI]
In a filter entry, when an HTTP-redirect action was added, then unconfigured, and then
added again with the same target URL, the redirect functionality on the CPM/CFM was not
activated and all matching traffic was not redirected but dropped, even though the filter was
correctly configured. This issue has been resolved. [139534-MI]
A system alarm is no longer generated for the removal of an unprovisioned IOM/IMM,

MDA/CMA, XCM, XMA, SFM or MCM. [141218-MI]
When 50 discovered PTP peers had active sessions with a 7750 SR Boundary Clock, if a
High-Availability switchover was performed, the new standby CPM/CFM remained in
PTP Recovery State: Initial indefinitely. To allow the standby CPM/CFM to reach PTP
Recovery State: Locked, at least one (1) PTP discovered peer must have expired or been
cancelled. This issue has been resolved. [142206-MA]
A node could have been blocked from SSH access if an SSH client already aborted the
session while the server was still processing output from the SSH client. This issue was
more likely to have been seen when scripts were used and could have been avoided by
always waiting for the CLI prompt to return before closing the SSH connections. This issue
If a 7750 SR Boundary Clock had no best master selected and was propagating an ARB
timescale with Time Source equal to internal_oscillator, the time conversion between TAI
and UTC used 34 leap seconds. The same applied for a 7750 SR ordinary master. This issue
On MDAs that support DS3 subrate, it was possible for the user to set up a subrate on the
command line with rate-step = 0. This did not affect ports where the subrate was
configured properly. This issue has been resolved. [143169-MI]
An IPv4 packet with a protocol type of ICMPv6 (neighbor discovery/solicitation) would

have been dropped by Layer-2 services if the hop limit was not 255. This could have
happened when injecting IPv4 packets with random header fields (including the protocol
field) with a packet generator. This issue has been resolved. [143770-MI]
Using SCP to get a file that does not exist no longer causes a small memory leak. [143828MA]
An administrative state change log event is now generated when the administrative state of
an MCM card is toggled (shutdown/ no shutdown). [144847-MI]
Synchronization of the standby CPM with the active CPM was not done correctly for a
filter-id applied to log-id 99 or to log-id 100 when a different filter-id than the default 1001
was configured. Filtering would no longer work after a CPM/CFM High-Availability
switchover.The CLI output of show log log-collecter would show that the applied filter-
285
Resolved Issues
id for log-id 99 was zero 0 instead of the configured filter-id value. For log-id 100, it
returned to the default applied filter-id of 1001. The workaround was to remove and
reconfigure the filter-id. This issue has been resolved. [145177-MI]
286
The value returned by the ifConnectorPresent MIB object was not False (2) for routed
interfaces. This issue has been resolved. [145675-MI]
Fan removed alarms are no longer generated on an XRS after a High-Availability CPM
switchover. [146571, 147692-MI]
If an SNMP-get or SNMP-set for any object in the sysSyncInfo table was received by the
system during synchronization of the configuration or boot environment, all subsequent
SNMP requests would not be processed until the synchronization was complete. SNMP
trap notification was not affected. This issue has been resolved. [147035-MI]
The state of the TACACS+ server no longer goes operationally down when certain SSH
clients (e.g., PuTTY) terminate an SSH session without logging off the TACACS+ user
first. This only occurred if TACACS+ Accounting was enabled. The TACACS+ server
became operationally up again after the next TACACS+ user login attempt or after the next
TACACS+ server health check. [148993-MI]
In releases prior to Release 11.0.R1, the configuration of the password authentication-order

incorrectly allowed duplicate entries in the list of methods. Duplicate configurations are
now blocked. Configurations containing a duplicate entry (e.g., authentication-order
tacplus local tacplus) will be automatically updated to remove the duplicates during an
upgrade. Duplicates are removed by evaluating the list from right to left: the third method
is first removed if it is not unique, then the second method is removed if that is still not
unique. [149874-MI]
A redundant alarm stating administrative state:outOfService, operational state: inService

is no longer generated when an MDA/XMA is manually shutdown. [150676-MI]
In certain scenarios where the node timing was synchronized from the BITS port, it was
possible that after the BITS port went down and recovered, the node would have remained
synchronized to another secondary reference instead of reverting back to the BITS port.
When the firmware of a certain hardware component is of a lower version than the latest
release but still an acceptable version, this will no longer be reported as a version mismatch
on the console interface but will now be reported as an acceptable but lower version.
[152984-MI]
ATM IMA
When physical links that were part of an IMA bundle bounced while they were in a
loopback configuration or when the physical ports were misconnected, IMA performance
degradation might have resulted. This problem has been resolved. [135583-MA]
LAG
When a member link with a speed different from the default one was added to a LAG, the
LAG bandwidth passed to IGP was incorrectly calculated based on the default speed. This
occurred when the LAG was becoming active while the newly-added member link
corresponded to the lowest port-id and was in the down state. This issue has been resolved.
[131442]
In an MC-LAG setup, activity will now switch over from the active PE to the standby peer
after a uni-directional failure takes place that causes LACP packets from the PE to the CE
to be dropped. [136264-MI]
Resolved Issues
Management
If a High-Availability switchover occurred on a system before any LAG was configured, all
LAGs created afterward would send LACP packets at double the normal rate on active
member ports. This did not affect LACP functionality. A subsequent High-Availability
switchover could be performed to restore correct LACP packet sending rate. This issue has
When using the auto-mda or auto-iom option to create LAG subgroups, it was possible to
exceed the current limit of eight (8) subgroups per LAG. If that happened, system
instability would result, and the configuration would need to be changed before the system
could recover. This issue has been resolved. [141381-MI]
Hashing of multi-destined packets (supported on B-VPLS and Ethernet Ring) egressing on

LAGs with member ports sprayed across different XMAs but on the same XCM might
have been dropped. This issue did not occur if the LAGs had ports provisioned on different
XCMs as long as on each of them, all the ports of a given LAG are within the same XMAs.
When a LAG with LACP enabled contained multiple ports and those ports had ETH-CFM
enabled, there was a small chance that one of the LAG ports would stay down after a node
reboot or line card reset. A workaround was to disable either LACP or ETH-CFM on those
ports. This issue has been resolved. [144223-MI]
When management connectivity was lost, the system might not have logged the SNMP
trap-replay notification associated with an IPv6 trap-target server and might not have
reported the number of the first unsuccessfully trapped event. This issue has been resolved,
and only affected the first IPv6 trap-target notification, and only when the system lost
management connectivity. [124839-MI]
After a system reboot, an in-band managed system configured for SNMP trap replay might
have, on rare occasions, failed to deliver the SNMP agent cold start trap to the trap
receiver. This issue has been resolved. [126681-MI]
When a system configured for trap-replay was managed in-band and only the next-hop
changed on an existing route, the system might have buffered, then replayed, any saved
SNMP traps only after the next trap raising event occurs. This issue has been resolved.
[137430-MI]
Specific system applications in SR OS, such as SNMP replay, can take action based on a
route to certain IP destinations being available. A configurable delay can now be
configured between the time that a route is determined as available in the CPM/CFM, and
the time that the application is notified of the available route. This delay may be used, for
example, to increase the chance that other system modules (such as line cards) are fully
programmed with the new route before the application takes action. Currently, the only
application that acts upon these route available or route changed notifications with
their configurable delays is the SNMP replay feature, which received notifications of route
available to the SNMP trap receiver destination IP address. [140321-MI]
The show snmp counters command wrongly displayed negative numbers for counters
that exceeded the value of 2147483647. This issue has been resolved. [144020-MI]
An SNMP GET-NEXT operation on vRtrIsisMtPathTable and vRtrIsisPathTable might

have incorrectly failed. This issue has been resolved. [145598-MI]
Traps are now sent out with the proper notify-community when multiple trap-targets with
different notify-communities are defined in a single snmp-trap-group. [145847-MI]
287
Resolved Issues
The up-time of the local system IP address interface is no longer reset after a HighAvailability switchover. [119625-MI]
When working on communities under config>router>policy-options# and issuing the

command "show router policy-edits" before the "abort" command could have generated an
unexpected behavior in that a sequence of "begin/commit" would have been able to trigger
a protocol update as the policies are being re-applied. This issue has been resolved.
[142480-MI]
The regular expression end-of-line marker $ on route policy community entries would
incorrectly match longer entries than allowed by the end-of-line-marker. For example,
1234:9(.?)(.?)$ would incorrectly match 1234:9001 when it should have matched values
1234:9[0..9][0..9]. This issue has been resolved. [144450-MI]
Large amounts of CPM- or CFM-originated traffic (e.g., ICMP packets) for which the nexthop is constantly and very rapidly changing no longer increases the system memory usage.
[144566-MI]
Executing the tools dump router route-cache command on an unresponsive telnet/SSH

session no longer causes a High-Availability switchover. [148117-MI]
ICMP port unreachable messages were wrongly sent from an interface that was configured
with icmp no unreachables. This issue has been resolved. [148958-MI]
In order to prevent the route cache from using a large amount of memory, the maximum
number of entries per routing instance is now limited to 20,000. [149011-MI]
FIB updates on an 7950 XRS were slower than expected if an XCM card was provisioned
but both XMA/C-XMA cards in that XCM were down for some reason. The workaround
was to un-provision the XMA/C-XMA card in that case. This issue has been resolved.
[150247-MI]
Filter Policy
When an IP filter action was changed to forward next-hop and then to http-redirect, the
actual action stayed on forward next-hop. The workaround was to change the action first
to drop and then to http-redirect. This issue has been resolved. [142987-MI]
IPv6
Unicast Neighbor Solicitation packets destined to the IPv6 link-local address are now
correctly classified. [131916-MI]
Due to an enhancement to the way IPv6 FIB entries are stored on the line card, the Current
Occupancy value in the FIB summary table may not have correctly reflected the FIB
table's true utilization. Consequently, the system may not have generated warning traps if
the IPv6 utilization exceeded the systems predefined thresholds. This issue has been
On very rare occasions, while moving a subnet to another subscriber-interface and when
this node is the second DHCP relay, snooping and processing a DHCP boot reply might
have resulted in a High-Availability switchover. This issue has been resolved. [133942-MI]
The sum of the number of characters in the server name and pool name should not have
exceeded 52 characters in case of a DHCPv6 local DHCP server. This issue has been
If the DHCP local server had both use-pool-from-client and use-gi-address scope pool
configured, a client DHCP boot request message without having pool information present
Routing
DHCP
288
Resolved Issues
would have only been offered an address out of the subnet where the gi-address belonged.
Other subnets in the pool were rejected even though use-gi-address scope pool was
configured. This issue has been resolved. [139354-MI]
After recovery from partnerDown state, leases that belonged to a remote subnet could
still have unicasted a DHCPRelease to the local DHCP server if a client disconnected
before a rebind was executed. Prior to Release 11.0.R1, the local DHCP server ignored this
DHCPRelease since the subnet was remotely controlled in normal state. The result was
that the lease state stayed allocated for the remaining lease-time, which was typically less
than MCLT time in this scenario. Starting in Release 11.0.R1, a DHCPRelease is always
processed when security checks pass, independent of whether DHCPRelease is received on
the local or remote DHCP server. [150659-MI]
A local DHCP server with dhcp-server persistency enabled, in rare cases, could have
silently dropped boot reply messages when persistency processing was slow. This issue has
been resolved. Processing of duplicate or flooded DHCPv6 boot requests has also been
enhanced. [151684-MI]
NTP
If a source address was configured for NTP via configure system security sourceaddress application ntp, the specified IP address would have been incorrectly used as the
source IP address for all NTP packets sent in the default router instance. It should have
only been used when transmitting unsolicited packets. This issue has been resolved.
[144096-MI]
IPsec
In a scaled IPsec configuration (500+ tunnels) with symmetrical and asymmetrical timer
values for IPsec and ISAKMP lifetime, the system might have experienced tunnel
instability during phase one (1) and phase two (2) rollovers. This issue has been resolved.
[129545, 133285-MI]
In a scaled IPsec configuration with symmetrical ISAKMP lifetime timer values, some
tunnels might have remained operationally down after rollovers. This issue has been
In scaled IPsec systems with asymmetrical timers where the IPSec SA lifetimes on the
Initiator and Responder were significantly different (i.e., Responder's IPsec SA lifetime
was ten times or more than that of the Initiator), the responder might have reached the
maximum number of available Security Parameter Indices (SPIs). This issue has been
Prior to Release 10.0.R3, when IPsec was enabled on the 7750 SR-c12, high priority
packets colliding/interleaving with low priority packets due to incorrect context switching
on the MCM might have caused packet loss. This issue has been resolved. [136249-MA]
After IKEv2 SA re-keying, outbound traffic could have been temporarily discarded when
the far-end node deleted the old SA within 25 seconds after re-keying. This issue has been
In the output of the show ipsec tunnel tunn-name command, phase 2 Established Time
has now been changed to read Installed Time. [145687-MI]
The MS-ISA card might have reset for IKEv1 IPsec static LAN-to-LAN configurations
upon receiving and needing to process an IKE message with a deleted payload that had a
DOI field equal to zero (0). The workaround was to use IKEv2 or dynamic LAN-to-LAN
configurations. This issue has been resolved. [148620-MA]
289
Resolved Issues
IS-IS
OSPF
290
GRE/IP-IP tunnels should not have been configured to use the same tunnel group as MCIPsec tunnels because traffic hitting the standby tunnel group would have been shunted or
dropped (if the shunt is not configured). This issue has been resolved. [149276-MI]
In rare occasions, IS-IS would have regenerated its LSPs after a High-Availability
switchover, triggering an SPF calculation (and an LFA SPF, if configured). This issue has
LDP FRR without IP FRR might have had a negative impact on regular IP convergence up
to a factor five (5). It was recommended that both IP and LDP FRR were enabled to avoid
the negative impact of Fast LDP FEC convergence on IP IGP route downloads. This issue
A small fraction of external routes leaked into IS-IS might have been purged for up to 10
seconds after a High-Availability switchover. This issues has been resolved. [137150,
137886-MI]
All LSPs with the lfa-only flag set will no longer be included in IS-IS endpoint calculation,
which in turn is used by LDP for LdpOverRsvp 7.0 style. [139567-MI]
If an IS-IS node first received an external IS-IS route from another IS-IS node and then
exported a local route with a lower preference and the same prefix into IS-IS, the received
external route was incorrectly not replaced by the local route in the IS-IS L2 database. This
The IS-IS metric is no longer incorrectly set to one (1) for an IS-IS interface if a reference
bandwidth is configured and the previously configured metric is removed. [144839-MI]
When changing an interface to unnumbered from numbered and the interface was used in
IS-IS, the interface type was set to broadcast instead of point-to-point. The workaround
was to change the interface type under IS-IS to no interface-type, which sets the interface
to point-to-point. [147808-MI]
In Release 10.0.R1 and up to Release 10.0.R7, disabling hello authentication only in Level
2 would not take effect and the node would still use authentication for Level 2 hello packets
if authentication key and type were also configured. The workaround was to also disable
hello authentication at the global level or at Level 1. This issue has been resolved. [149420MI]
A route policy entry from 'area' will no longer match other protocols if protocol OSPF was
not specified explicitly. [88118-MI]
Changing the OSPF router ID to an IP address that previously existed in the network might
have resulted in a failed CSFP computation to reach the newly configured router ID. A
workaround was to configure a temporary loopback interface on the node where the router
ID was modified and add the loopback address to OSPF. This would cause the node to
generate a new router LSA and clear the problem. This issue has been resolved. [132590MI]
OSPF import policies might not have been used while OSPF superbackbone was active in a
given VPRN service. This issue has been resolved. [134184-MA]
All LSPs with the lfa-only flag set will no longer be included in OSPF endpoint
calculation, which in turn is used by LDP for LdpOverRsvp 7.0 style. [139723-MI]
In a multi-chassis environment, OSPFv3 updates for exported directly-connected /127

subnet routes sent from one of the routers to the other would not be installed in the IPv6
Resolved Issues
routing-table if the routes existed locally but were not active. A workaround was to
configure these interfaces as passive OSPFv3 interfaces on both routers or use appropriate
static routes. This issue has been resolved. [142337-MA]
BGP
When an OSPF instance had LDP-over-RSVP or RSVP-shortcut enabled, in rare cases, a

modified or updated tunnel could have been incorrectly torn down before another tunnel
was correctly deleted. This issue has been resolved. [143140-MA]
When changing an interface to unnumbered from numbered and the interface was used in
OSPF, the interface type was set to broadcast instead of point-to-point. The workaround
was to change the interface type under OSPF to no interface-type, which sets the
interface to point-to-point. [147446-MI]
In an OSPF configuration where an interface belongs to two different areas and Area 0 is
not configured, shutting down the primary OSPF interface no longer results in OSPF routes
not being properly removed from the route-table. [148104-MI]
When the operational status of an interface changed, causing a new router LSA to be regenerated, OSPF no longer re-generated all of the opaque LSAs in the area. [150401-MI]
In very rare cases, malformed or corrupted BGP packets could have triggered a reset of the
standby CPM/CFM. This issue has been resolved. [106589-MI]
TCP sessions might have flapped in a scaled setup when the show system connections
command was issued with environment no more and there were more than 5000 BGP
peer sessions. This issue has been resolved. [112610-MI]
BGP multipath routes might not have been installed as expected if routes with different
next-hops were received in a dual route-reflector configuration. This depended on the order
in which routes were received. This issue has been resolved. [116280-MI]
When igp-shortcut is enabled under BGP, traffic originating from a node to a tunneled nexthop will no longer be dropped if a loopback interface address is deleted while the interface
is still enabled. A workaround was to shut down the interface prior to deleting the address.
[128651-MI]
BGP peers will no longer reset when the BGP remove-private configuration statement is
added, removed, or modified. [133790-MI]
A line card or CFM reset will no longer occur in a scaled 6PE environment where ECMP
and Multipath were both configured. [137572, 138111-MA]
The route preference was not always correctly compared between a BGP and a BGP-VPN
route if the same BGP-VPN route was imported by another VPRN on the same PE router
with a modified route preference. This issue has been resolved. [140913-MI]
BGP keepalive messages are now sent at regular intervals based on the configured
keepalive timers without variation. [141755-MI]
BGP no longer re-evaluates its installed routes when IGP updates the RTM or the TTM
with a Loop-Free Alternate (LFA) next-hop only. Thus, the BGP route age will no longer
get reset. This issue has been resolved. [142192-MI]
If there were routes in the BGP RIB-IN whose BGP next hop could be resolved through
either another BGP route or a less specific IGP route, when the bgp>next-hopresolution>use-bgp-route command was enabled or disabled, those route's next hops might
not have been re-evaluated correctly. This issue has been resolved. [143041-MI]
The active CPM/CFM will no longer reset under certain scenarios when the system runs
out of MPLS NHLFE or MPLS labels resources. This could happen when a node,
291
Resolved Issues
configured as ASBR with Inter-AS option B, received many BGP-VPN routes with unique
labels. [144474-MA]
MPLS/RSVP
292
When a BGP-MH site was administratively brought up in current non-DF or shut down in
current Designated Forwarder (DF), a short duration of traffic loop might have been
observed. The traffic loop happened due to declaration of non-DF in BGP-MH NLRI by
the node bringing down the site before local acknowledgement of forwarding status.
[145447-MI]
An active CPM/CFM reset will no longer occur when the system runs low on memory due
to an excessive amount of unique 6PE routes being received. The BGP peer(s) that
receive(s) the routes will now be disabled in this case and memory will be released.
[145976-MA]
Generating a route-refresh message no longer resets the keep-alive interval. This could
have resulted in a delay in sending out keep-alive messages and in the peer node taking
down the peer due to hold-timer expiration. [147019-MA]
Routes are now properly aggregated when exported to BGP and summary-only is used in
the aggregate route. [147239-MI]
The interval at which a BGP keep-alive is sent will now be dynamically changed if the
BGP keep-alive timer is modified after a peering session is already established. [147338MI]
Support for draft-ietf-idr-optional-transitive has been disabled because this draft is no

longer active and it was causing BGP interoperability issues. The updated-error-handling
configuration option in the BGP group and neighbor contexts has been deprecated.
[150006-MA]
BGP will now reset all reserved attribute flag bits to zero (0) whenever it propagates an
unknown optional transitive attribute that may have some of the bits set to one (1). These
bits were already reset to zero (0) for known attribute types. Also, BGP will continue to use
the most appropriate length encoding when sending attributes, but will now accept standard
and extended length encoding for all attributes. [150008-MI]
p2mp-lsp-ping ldp-ssm echo requests encoded the wrong FEC type, 0x15(21), when it
should have actually been 0x13(19). This issue has been resolved. [135376-MI]
A head-end failure of an LSP that is used for LDP-over-RSVP will no longer result in
multicast and broadcast traffic being dropped in a VPLS. For this issue to occur, ECMP had
to be enabled with multiple LSPs to the destination and Fast-Reroute (FRR) or a standby
path with the same cost as the primary path that failed had to be enabled. [137523-MA]
Incoming RSVP PATH messages with a zero-length session name in the session attribute
will now be accepted so that interoperability is now possible with certain third-party
devices that are unable to include a session name. [139102-MI]
Adding a port to a LAG will no longer result in broadcast and multicast traffic being
dropped in a VPLS service that is using LDP-over-RSVP where the LSP egresses the LAG
interface. [139247-MA]
When multiple least-fill LSPs were set up to the same destination which was one hop
farther and had multiple ECMP point-to-point links available, worst link bandwidth usage
was kept as reference while processing all ECMP links. As a result, the algorithm always
picked the last investigated link instead of randomly selecting one from the available
ECMP links with equal bandwidth usage. This issue has been resolved. [141314-MI]
Resolved Issues
The iLDP multicast-traffic option did not inherit the correct default value, and thus,
MBB/P2MP capability flags were not set accordingly. This issue has been resolved.
[102419-MI]
Modifying the LDP hello timers while the hello adjacency was up did not come into effect
until the adjacency bounced. However, after two High-Availability switchovers, the active
CPM or CFM would start using the new timer value. This issue has been resolved.
[112617-MI]
Receiving a timestamp echo reply with a value of zero (0) within the TCP timestamp
option (TSopt) extension will no longer cause a delay in TCP retransmissions, which could
have caused LDP or BGP peerings to time out. [137885-MA]
IP Multicast
In a VPLS configured for IGMP-snooping and MCAC, the command show router mcac
policy no longer incorrectly displays the Mand Pre-rsvd BW value in the Avail Opnl
BW output. [138266-MI]
PIM
If the multicast route to the source in a source mVPN toggled, some of the extranet (S,G)s
might not have been resolved in the receiver mVPN. This issue has been resolved.
[133724-MI]
In a multicast VPN extranet configuration, a system reboot would occur if an IGMP leave
was received on an IGMP interface in the receiver mVPN. A workaround was to enable
PIM on all IGMP interfaces in the receiver mVPN. This issue has been resolved. [135920MA]
When the uptime of one or more PIM group(s) wrapped around at the 32-bit boundary and
the groups were re-balanced over ECMP links at the same time, there was a small chance
that PIM CPU usage became high because the MFIB of the affected PIM group(s) was
continuously being updated. This issue has been resolved. [142778-MI]
When rpf-table both was configured and only multicast routes were populated, a
CPM/CFM High-Availability switchover could have occurred upon adding a multicast
route with an invalid PIM next-hop. This issue has been resolved. [152805-MA]
When per-fp-ing-queuing was enabled, all of the statistics for a LAG were bound to one of
its ports if multiple ports were configured in the LAG from the same forwarding complex.
If that port in the LAG was removed and re-added, the statistics would have been cleared.
This issue has been resolved and the statistics are now preserved for the LAG until the last
member port is removed from the same forwarding complex. [76443]
The show commands for LAG-based SAPs, show qos policer sap lag-1 or show qos
queue sap lag-1, now properly display matching entries. [134323-MI]
After removing a queue-group network instance from the ingress Forwarding Plane (FP), it
was necessary to remove all references to this queue-group. If this step was omitted, it
could have resulted in ingress SDP-bindings or network interfaces referring to a different
queue-group instead of the default network queues. This issue has been resolved.
[134434-MI]
In specific configurations of FP ingress queue-groups, an error trace was seen while issuing
the show command "show qos policer card card fp fp-id queue-group queue-group-name
instance id access|network ingress detail".
LDP
QoS
293
Resolved Issues
The error only occurred when the FP ingress had the same queue-group-template and the
same instance ID instantiated at both access and network. The show command output was
still displayed correctly otherwise. This issue has been resolved. [134473-MI]
The QoS override configuration did not work for services on channelized MDAs following
a CPM/CFM activity switch. It might also not have worked following a reboot. A clear
operation on the MDA or card or a reconfiguration of the QoS override parameters would
restore the expected traffic forwarding behavior on the affected services. This issue has
Dynamic Q2 Wred Pools might have been under-allocated in tools dump systemresources. In very rare cases, an old configuration file might have failed to load due to
resource exhaustion. This issue has been resolved. [138156-MI]
The H-QoS throughput rate could have been slightly inaccurate at low rates when fast-start
was enabled in the "adv-config-policy offered-measurement" context. This issue has been
Queue- or scheduler-override configuration statements were sometimes not properly

applied to SAPs on some line cards in two cases:
-
After a High-Availability switchover on ports of an MDA if the other MDA on the

same IOM was not inserted.
After a node reboot of a node with a scaled number of routes and SAPs.
294
A QoS-scheduler with frame-based-accounting enabled that was configured on a SAP,

whose context also had a slope policy configured, could have resulted in continuous resets
of the IOM/XCM that contained the SAP. This issue was only present in 10.0.R4 and has
now been resolved. [144507-MA]
FP3 profile-mode queues are now consistent with FP2 profile-mode queues. Explicit inprofile traffic will remain in-profile and will not be subject to the profile-mode queue's
CIR. [145380-MI]
A change from percent-rate to rate in a queue-group queue is no longer incorrectly blocked

after all percent-rate queue overrides are removed. [145845-MI]
Adding or removing LAG members while egress encap group(s) were present on the LAG
might have resulted in resource inconsistencies. This issue has been resolved. [146152-MI]
Cflowd IPv6 traffic was not mapped to the proper forwarding class queue based on sgt-qos
configuration. This issue has been resolved. [147916-MI]
In cases where the MBS and CBS settings on a queue had similar or equal values, in rare
cases, some packets through that queue could have been dropped if the shared buffer pool
was depleted but the reserved buffer pool was not. [149831-MI]
It was possible to apply the same network QoS policy with a scope of exclusives under
multiple CLI contexts. It was advised to make sure that any violations where the same
exclusive network QoS policy was applied under multiple contexts be corrected prior to an
upgrade. A saved configuration file that contains a violation will now fail to load. [150617MI]
Configuring a percent-rate for a queue under queue-override on a VPRN SAP was

incorrectly blocked in CLI. However, it was possible to correctly configure it through
SNMP and a saved configuration with this value set through SNMP would have failed to
execute on boot up. [164625-MI]
Resolved Issues
Services General
A gratuitous ARP might not have been sent out if a SAP was added to an interface that was
administratively up with a configured address. A workaround was to toggle (shutdown/no
shutdown) the interface. This issue has been resolved. [129966-MI]
HTTP-redirect performance might have been slower than expected. This issue has been
When two hosts, belonging to different services and sharing the same IP address, each open
a TCP connection with the same source and destination TCP ports that hit an HTTPredirect filter at the same time, one of the TCP connections could have been dropped. This
A physical port can be a member of several Ethernet tunnels and a physical port that is a
member port of an Ethernet tunnel can have SAPs from other services configured on it. As
such, the pool QoS configuration of the physical port does not need to be the same as other
members of the same tunnel. Checks between buffer pools and Ethernet tunnels have been
removed, allowing users to configure the pools on ports according to their needs. [136719MI]
If ingress mirroring of a LAG member port in mirror service A and egress mirroring of the
same LAG member port in mirror service B was configured and one of the configurations
was removed, an invalid configuration could have occurred when the user proceeded with
mirror configuration on the parent LAG port. This issue has been resolved. [138875-MI]
When a spoke-SDP-terminated interface became active, it was possible that the gratuitous
ARP would have been dropped if the data plane was not programmed in time. This could
have been an issue in a PW active/standby topology where there would be different MAC
addresses for each redundant spoke-SDP-terminated interface. A workaround was to
configure a static MAC address. This issue has been resolved. [141989-MI]
The system now blocks the user from applying filters that include VLAN Identification
(VID) entries on a mesh-SDP. The following error message is displayed "MINOR:
SVCMGR #2611 Can not apply filter containing VID-type entries on a mesh sdp". It was
correctly blocked for regular spoke-SDP, and B-VPLS configurations already. [142364,
142464-MI]
Cpipes in a scaled multi-chassis (MC) environment with MC-APS SAPs assigned to an

endpoint could, in rare cases, have stopped forwarding traffic after several MC-APS
switchovers. This issue has been resolved. [142735-MA]
PBB-Epipe UP MEPs with CCM enabled did not come up when B-VPLS was managed by
SPB with different unicast and multicast forwarding tree topologies. This issue has been
Deleting and recreating a multi-chassis endpoint might have resulted in the endpoint
SR OS continuously transitioning from non-multi-chassis to multi-chassis state and back.
To avoid this condition, deletion of the service should have happened on one node at a time
and not simultaneously on both nodes with a bulk delete from Alcatel-Lucent 5620 SAM.
In VLL BGP-MH, when the network endpoint SDP binding became operationally down on
a designated forwarder (DF) node, the site became non-DF and sent a MH-NLRI with the
down bit set. Prior to Release 10.0.R7, on the first event that brought the network endpoint
up, the down bit was incorrectly not cleared. This resulted in the node that should have
became DF to stay in a non-DF state. Subsequent events like a second binding coming
operationally up within the same endpoint cleared the down bit and the node assuming DF
state. This issue has been resolved. [147696-MA]
295
Resolved Issues
Subscriber
Management
296
When multiple BGP-MH sites were present in a VPLS service and one of the sites was shut
down, BGP-MH unreachable NLRIs were sent for all of the sites in the service. This issue
has been resolved, and now a BGP-MH unreachable NLRI will only be sent for the site that
was shut down. [152200-MA]
All DHCPv6 servers in the same node could have had the same DHCPv6 Unique Identifier
(DUID) since there was no redundancy between DHCPv6 servers. ESM DHCPv6 relay on
group interfaces should only have been configured to relay to only one local DHCP server:
either locally configured or on a remote node. This issue has been resolved. [104244-MI]
RADIUS Acct-Session-Time had an incorrect value in the Stop or Interim-Update

message when the system time was changed after a lease was populated and a RADIUS
Accounting Start message was generated. This issue has been resolved. [118880-MI]
Traffic destined to a configured and delegated IPv6 subscriber prefix anycast address (::0)
was incorrectly forwarded via CPM/CFM and might have resulted in traffic loss or a
different QoS treatment. This issue was only present for the local configured prefix and not
for all other anycast addresses that are delegated and part of the local configured subnet
prefix. This issue has been resolved. [132801-MI]
The system might have become unstable when a persistence downgrade was performed
using tools perform persistence downgrade. Performing a persistence downgrade was not
supported prior to Release 10.0.R3 due to this issue. This issue has been resolved. [132995MA]
IPoE-SLAAC host RADIUS QoS override is now applied when instantiated via AccessAccept message or when a CoA message is received for the linked IPv4 dual-stack host.
[133219-MI]
File deletion of the subscriber-management index persistency file (submgmt.i08) on the

compact flash when persistency is enabled no longer results in system instability. [133754MI]
When connection with the RADIUS server was lost and RADIUS fallback was executed
upon a DHCP renewal, the existing sub-id might not have been found back for a lease with
nh-mac anti-spoofing enabled. This caused the lease to change from sub-id and a
corresponding event was logged. This issue has been resolved. [134503-MI]
When host-accounting and session-accounting were both enabled in a RADIUS

Accounting policy, loading of the saved configuration file after a reboot might have failed.
A workaround was to edit the configuration file after saving and to move the "no queueinstance-accounting" line before the "host-accounting" line. This issue has been resolved.
[134696-MI]
When multiple IPv6 subscriber hosts (DHCPv6 ESM or PPPoE ESM) with both a PD
prefix and a wan-host address or prefix were terminated on the same SAP and the
delegated-prefix-length was not set to 64, egress traffic destined for the wan-host prefix of
these hosts (IA_NA address or SLAAC prefix) might not have traversed the queues of the
correct subscriber host. The traffic would end up on the correct host only if both hosts were
connected to the same SAP. This issue has been resolved. [136134-MA]
In case of volume-based credit control, the out-of-credit action might not have been
respected and traffic could still be forwarded for a subscriber connected via a LAG that had
members located on different IOMs/IMMs/XCMs. When all members of the LAG were
part of the same IOM/IMM/XCM or when time-based credit control was used with default
Resolved Issues
setting no activity-threshold, this issue did not occur. This issue has been resolved.
[136204-MA]
In case a QinQ capture-SAP had a port outer Ethernet type value configured different from
the default value 0x8100, and authentication-policy used as access method pap-chap,
the PPPoE PADO message was incorrectly sent out of the MSAP with the default outer
ether-type 0x8100. This was not an issue in case the capture-SAP was dot1q-tagged or the
authentication-policy used was different from pap-chap. This issue has been resolved.
[136535-MA]
When displaying the ARP table for a specific MAC address using show router arp mac,
subscriber interfaces are no longer wrongly included in the output. [136562-MI]
With DHCPv6 relay enabled, a DHCPv6 RENEW message with only an IA_PD IPv6
delegated prefix present could have incorrectly caused the removal of the IA_NA IPv6
lease state. Similarly, a DHCPv6 RENEW message with only an IA_NA IPv6 address
present could have caused the removal of the IA_PD IPv6 delegated lease. This was not an
issue when both IA_PD and IA_NA were present in the DHCPv6 RENEW message. This
The system now supports the use of DHCPv6 option 18 (Interface Identification) for
RADIUS authentication of an LDRA packet in an MSAP capture-SAP configuration.
[137047-MI]
Scaling of non-IP hosts, statically configured with the non-sub-traffic command in the
sap>sub-sla-mgmt>single-sub context, was lower than specified starting from Release
9.0.R1 onwards. This issue has been resolved. [138469-MA]
Having match-circuit-id enabled within the DHCP context of a group interface might
have led to system instability or an immediate High-Availability CPM/SFM switchover.
Configuring match-circuit-id is only required when DHCP packets with the same MAC
address enter the same SAP and do not have a unique transaction ID, which is normally
always the case. This issue has been resolved. [139118-MA]
Multicast is now supported for MLPPP subscribers terminated on LNS. [139979-MI]
An SNMP walk on the tmnxSubPppSvcTypeSessions MIB object might have slowed down
processing of PPPoE and ICMP packets. This issue has been resolved. [141215-MA]
When a PPPoE client failed NCP, it was possible that the PPPoE session was not correctly
updated on the standby CPM which, in rare cases, could lead to a reset of the standby CPM.
In a scenario where a subscriber which had one-time-http-redirection configured in its slaprofile and the host was in the triggered state while persistency was enabled, if one-timehttp-redirection was removed from the sla-profile, the configuration was saved, and the
node was manually rebooted, the active CPM would have continued to reset. Manual
intervention (e.g., pull out the persistency file compact flash) was required to recover the
node. This issue has been resolved. [142107-MA]
When multi-chassis-sync (MCS) was started from a node that had many IGMP hosts and
states, only the first few hundred would be syncd initially. The rest would be syncd when
there was a refresh of the IGMP states by the hosts. This issue has been resolved. [142463,
143380-MA]
When ESMv6 Unmatching prefixes support was disabled, it was still possible to
instantiate IPv6 subscriber hosts with PD prefixes that had a delegated-prefix-length other
than the one configured on the subscriber interface (by giving a different prefix length
through RADIUS). Creating these types of hosts was not recommended; the delegated
297
Resolved Issues
prefix length from RADIUS should have been kept the same as the one configured on the
subscriber interface. This issue has been resolved. [142565-MI]
298
Untagged ARP, DHCP and DHCPv6 packets for subscriber host creation received on a vctype ether, dot1q PW-port SAP with explicit zero (0) encap (e.g. SAP pw-<pw-id>:0) are
now correctly delivered. This kind of SAP can be used for untagged traffic to/from the
subscriber host. This means single-stack ARP host, single/dual-stack IPoE hosts or
single/dual-stack PPPoE hosts on PW-port are now fully supported for both vc-types
ether and vlan. [142732-MA]
Static routes could have pointed to a static ESM host as the next-hop address. When the
next-hop toggled because of a chassis reboot, a port flap or other root causes, in some
cases, the static route was incorrectly missing in the routing table. This issue has been
If a one-time HTTP-redirect was configured on the chassis and some of the HTTP-redirect
filter entries were removed, it was possible for the one-time-redirect module to lose
information about other currently active filter entries. In this case, the one-time HTTPredirect filter would have remained in active state (and would not have been removed),
even when the HTTP-redirect was triggered. This issue has been resolved. [145132-MI]
lsp-trace and p2mp-lsp-trace now include the Downstream Mapping (DSMAP) TLV when
the size option is used. The DSMAP allows each node in the path to validate the label stack
and interface from where the packet is received. [145683-MI]
Traffic to IPv6 PPPoE unnumbered hosts was incorrectly dropped when uRPF in strict
mode was enabled. This issue was has been resolved. [145968-MA]
From Release 10.0.R4 onwards, a Routed CO subscriber LAG SAP host that had joined a
multicast channel might have stopped receiving the multicast stream indefinitely after a
certain sequence of LAG or port events. This was the case when one of the LAG ports was
removed and added again. Afterwards, because of other events, this port became the
primary LAG link without having the LAGs operational state changed. A similar case
might have occurred when LAG links all resided on the same MDA and that MDA was
reset or cleared. This issue has been resolved. [147691-MA]
RADIUS Accounting Interim-Update messages were not generated in case the subscriber
had assigned an sla-profile that was not part of the first 255 configured sla-profiles under
subscriber management. This issue has been resolved and was only an issue for Accounting
Interim-Update messages and not for Accounting-Start or Stop messages. [147893-MI]
CPU usage of the Cards & Ports module could have been higher than expected during
stable network conditions when storing or updating lease state information at the end of a
persistency file. This issue has been resolved. [148002-MA]
An SNMP walk on the tmnxSLAProfInstIngPStatsEntry or

tmnxSLAProfInstEgrPStatsEntry MIB objects might have taken longer than expected or
caused a timeout of the SNMP walk when there was a high number of ESM subscribers
present that did not have QoS policers enabled. This issue has been resolved. [149206-MI]
If a High-Availability switchover was triggered shortly after a node reboot but before the
active CPM/CFM finished subscriber persistency recovery, the standby CPM/CFM might
have no longer stored new persistency records and the persistency file state would remain
in the INITIALIZED state on the standby CPM/CFM. A node reboot was required to
recover. This issue has been resolved. [149730-MI]
If a local DHCPv6 server would not assign any addresses, the ADVERTISEMENT
message in response to SOLICIT incorrectly put the "noaddrsavail" status code inside the
Resolved Issues
Identity Association (IA). Per RFC 3315 section 17.2.2, the "noaddrsavail" status code is
now moved to the top level. This issue has been resolved. [150294-MI]
VPLS
VPRN/2547
DHCPv4-over-IPv6 transport packets were incorrectly dropped because of draft-ietf-dhcdhcpv4-over-ipv6-xx. Starting in Release 11.0.R1, DHCPv4-over-IPv6 transport packets
are transparently, without interaction, forwarded via the IPv6 subscriber host queues.
[153527-MI]
Traffic ingressing on a service interface (that was associated with a LAG SAP that had
more than one member port on the same IOM/IMM) and egressing on an R-VPLS interface
might not have been flooded correctly to all egress SAPs in the R-VPLS. For unicast
unknown traffic, any configuration that prevented unicast traffic from being flooded in the
R-VPLS could have been applied as a workaround (i.e., local-age, disable-aging, staticmac). This issue has been resolved. [135408-MA]
CPM-/CFM-originated unicast traffic egressing on a routed VPLS (R-VPLS) interface

might not have been sent out if the destination MAC address was learned on an SDP with
multiple LSPs (RSVP or LDP). Transit traffic was not affected. This issue has been
IGMP Group Specific Query (GSQ) messages that were received on a VPLS port (SAP or
SDP) from an IGMP querier were incorrectly not forwarded to ports that were defined as
an mrouter port. This issue has been resolved. [137559-MA]
VRRP standby-forwarding should not have been used on Routed VPLS (R-VPLS)
interfaces if hosts in the R-VPLS reached the VRRP master router through the R-VPLS in
the backup router. This issue has been resolved. [138448-MI]
For STP/MSTP, the hold count range has been increased to a maximum value of 20 from
the old limit of 10. The default remains at six (6). A larger hold count value can improve
convergence in MSTP when there are more than four (4) MSTIs by allowing more BPDUs
to be sent per second. [141807-MI]
The log event sapTlsMacMoveExceeded would show an all-zero MAC address when
MAC-move blocked a BGP-MH SAP. MAC-move still worked as expected in this case,
but the log event was incorrect. This issue has been resolved. [146954-MI]
For some MAC addresses, the log event sapTlsMacMoveExceeded would show an all-zero
or partial-zero MAC address when MAC-move blocked a SAP. MAC-move still worked as
expected in this case, but the log event was incorrect. This issue has been resolved.
[148259-MI]
STP BPDUs that have a protocol ID of 0x000e received on an ATM SAP are no longer
dropped. [148835-MA]
For inter-AS VPRN, MPLS labels that were bound to prefixes sent towards eBGP peers
remained stale when the eBGP peers were removed or when the export policy was
changed. These labels would only have been released when the incoming prefixes were
refreshed or when the "enable-inter-as-vpn" config statement was removed and added
again. As a workaround, each time the BGP export policy for labeled prefixes on inter-AS
eBGP peers was changed, the "enable-inter-as-vpn" config statement should have been
bounced. This issue has been resolved. [114673-MI]
Using BGP as-override combined with local-as no longer replaces the CE AS number by
two (2) times the VPRN instance AS number. This issue has been resolved. [131617-MI]
299
Resolved Issues
VRRP/SRRP
PPPoE
300
In Inter-AS VPRN model B, the egress ASBR incorrectly copied the calculated inner
(VPRN) label TTL into the tunneled IP packet TTL for packets forwarded into the
Autonomous System. This issue has been resolved. [137501-MA]
Removing ignore-nh-metric under a VPRN context was not taking effect. A workaround
was to remove and reconfigure the VPRN. This issue has been resolved. [138405-MI]
If "maximum-routes log-only" was configured in a VPRN context, the VPRN behaved as if

maximum-routes was configured without the log-only option. This issue has been resolved.
[146332-MA]
In order to align the base routing instance behavior to VPRN, outbound updates towards
peers, configured with local-AS and AS-override, now contain at least two (2) times the
VPRN instance AS number in the AS path. This restores the behavior before DTS 131617
was introduced in Release 10.0.R4. [146405-MI]
mVPN routes are no longer lost after a CPM/CFM switchover when the mVPN vrf-import
and -export policies are configured with the keyword unicast. [148774-MA]
OSPF routes within a VPRN are no longer double-counted towards the maximum-routes.
The double-count occurred when a link flapped and the same OSPF route became
reachable via another OSPF interface in the VPRN. [150705-MA]
If a BGP next-hop is resolved through a static-route in a VPRN instance, the resolved nexthop is now updated correctly when the static-route is deleted. [151197-MA]
BGP route flaps on BGP neighbors in multiple VPRNs might have resulted in a node reset
if these BGP neighbors had import policies with a route-damping policy action. This issue
If an SRRP instance was deleted, the MCS peer might have incorrectly flagged
subnetMismatch for the remaining SRRP instances. A workaround was to clear the
SRRP sync-database. This issue has been resolved. [133107-MI]
Modifying the IP address on an interface before deleting all of its configured VRRP
addresses with SNMP could have resulted in a standby CPM/CFM reset. This issue has
The VRRP owner sent the first ARP request using the Virtual Router MAC-address but the
subsequent ones incorrectly using the local interface MAC-address. This issue has been
On rare occasions when data to be logged exceeded the allowed limit, a harmless trap
"svcMain:SUBMGR:sbmPppoeSessionFailureTrap detail buffer overflow" might have
been generated. This issue has been resolved. [128780-MI]
The initiator of an L2TP tunnel was allowed to select a source UDP port different from
1701 per RFC 2661. If 7750 SR was LNS, the incoming source UDP port was not
considered and replies were always sent to destination UDP port 1701. This might have led
to issues when interoperating with other vendors LAC devices that ignored incoming
replies with UDP destination port 1701 and expected a reply with the destination UDP port
that matches the source port used. This issue has been resolved. [134089-MA]
Leaking of a subscriber prefix from a retailer VPRN into a different local VPRN; or
leaking static, Managed or BGP routes that had a subscriber prefix as next-hop might have
updated the route-table of the local VPRN correctly but could have given a failure for the
FIB update "IOM:UNUSUAL_ERROR: find_and_use_ip_nexthop: Cannot have
Resolved Issues
IP_NEXTHOP on subscriber interface" or "RTM FIB add failed for VRF x prefix".
Besides traffic not being forwarded as expected for the leaked routes in the local VPRN,
the FIB update failures could have also caused IGP shutdown or other service impact when
many FIB updates were processed at the same time. This type of local VPN route leaking is
now blocked in software. [134840, 140643-MA]
Without unique-sid-per-sap enabled, a PPPoE session ID that had just failed to set up
was re-used again for the same MAC address. Some DSLAMs were slow to converge and
did not perform as expected with this behavior. In Release 10.0.R4, the next available
PPPoE session ID will be used instead of immediately re-using the same MAC address.
[138638-MI]
When the IP address of a PPPoE host was allocated via the internal DHCPv4 client, each
renewal of the DHCP lease could result in a small memory leak on the standby CPM/CFM
and eventually it could run out of memory and reset. The default requested lease-time by
the internal DHCPv4 client is 24 hours, resulting in a DHCP renew every 12 hours. The
workaround was to increase the DHCP server lease-time to a very high value. This issue
has been resolved and was only present in Release 10.0. [143481-MA]
Traffic from a Retail VPRN service destined to a route (e.g., managed routes) that had as
next-hop a PPPoE host part of a Retail VPRN could have been dropped or forwarded to the
wrong Retail VPRN in cases where the PPPoE host had an overlapping IP address with
another PPPoE subscriber host part of another Retail VPRN service with the use of privateretail-subnets. This issue was only present in case overlapping IP address PPPoE hosts
were present and for traffic that had as next-hop the PPPoE host. This issue was not present
for traffic forwarding to the PPPoE host. This issue has been resolved. [145541-MA]
IGMP
For (S,G) records already existing in the VPLS MFIB, an IGMP join on a new egress
forwarding complex no longer shows a higher than expected delay to forward multicast
traffic. [144504-MA]
NAT
No egress ACK was being sent when an HTTP-redirect filter was defined on a PPPoE or
DHCP subscriber with L2-aware NAT. The workaround was to use subscriber management
together with large-scale NAT (LSN). This issue has been resolved. [105240-MI]
L2-aware subscriber NAT was already supported for subscribers created on the LNS side.
Dual-stack is now also supported for L2TP and will no longer result in the following error
message: macsid-ip anti-spoofing is required for this PPPoE IPv6 host because the
associated sub-profile (sub-prof-nat-1) has a nat-profile (nat-l2-aware) configured.
[120735-MI]
The output of the show isa nat-group command was missing the description field header.
When an MS-ISA was removed or replaced in a NAT-group while handling LSN traffic,
some traffic that was handled by that MS-ISA might have been misrouted for less than one
(1) second. During this transition period, error traces might have appeared in the main
event log. This issue has been resolved. [132307-MI]
The MS-ISA used for NAT could have become unstable when RTSP was used with
fields/values proxy-require:nat.sun, require:nat.stun, or supported:nat.stun. The MS-ISA
used for NAT could have also become unstable when FTP was used with field
authorization. This issue has been resolved. [139164-MA]
301
Resolved Issues
The standby CPM might have failed to synchronize with the active CPM in some cases
after a standby CPM reset or a CPM switchover if there were NAT policies with pools that
were assigned to different NAT groups and share the same ipfix-export-policy. This
configuration could also result in IPFIX logging to not always work for one of the NAT
groups and the following event might have been logged: BB:UNUSUAL_ERROR Slot A:
bbNatUnbindVrtrFromNatGrp: Cannot find binding for VrtrId 2 natGrpId 2. The
workaround was to change the configuration so that every nat-group used a different ipfixexport-policy. This issue has been resolved. [143280-MA]
It was not possible to configure an IPFIX collector without a source IP address while it was
administratively enabled, even if the containing ipfix-export-policy was not associated
with any NAT policy. As a consequence, it was impossible to boot with a configuration file
containing such a configuration. This issue has been resolved. [143339-MI]
If an ipfix-export-policy that was shared by NAT policies using different NAT-groups was
removed from one of the NAT policies, the other policies would have also stopped sending
IPFIX information. The workaround was to make separate ipfix-export-policies for each of
these NAT policies. This issue has been resolved. [143637-MA]
No static-port forward (nat64 or dual-stack-lite) could have been configured if the natgroup had more than one active ISA-BB, and the subscriber-prefix-length configured in
nat64 or dual-stack-lite was not 128. This issue has been resolved. [145880-MI]
Receiving a corrupted TCP packet, where the length field in the tcp-options is wrong, when
tcp-mss-adjust is enabled within the nat-policy will no longer cause the MS-ISA card to
reset. [149759-MA]
When the TMS-interface was in the base instance, a shutdown of the IES service had no
impact. This issue has been resolved. [132631-MI]
After the admin redundancy synchronize boot-env CLI command was executed, the
system incorrectly generated a minor error message Class CPM Module: Optional file
cf3:\images\TiMOS-C-9.0.Rxx\peakflow-tms.tim is not present during sync operation.
Lawful Intercept
The Mac-Filter-Based Lawful Intercept Confidentiality Improvements feature had some

confidentiality limitations when managed via SNMP in Release 10.0.R1. Those SNMP
confidentiality limitations no longer exist in Release 10.0.R2.
PBB
On systems with PBB Epipe LAG SAPs configured, adding a new LAG member from an
IOM/IMM/XCM that already had members in that LAG might have impacted some traffic
flows through the LAG. However, adding a link from an IOM/IMM/XCM that did not
already have members in that LAG would not cause such an impact. This issue has been
After configuring IGMP-snooping mrouter-port on a B-VPLS SAP, system instability

might have occurred. The workaround was to enable IGMP snooping on the I-VPLS before
configuring the IGMP snooping mrouter-port on the backbone B-VPLS SAP.
TMS
The same problem existed when configuring an IGMP snooping mrouter port on a backbone B-VPLS SDP. Again, the workaround was to enable IGMP snooping on the I-VPLS
service first.
302
Resolved Issues
When booting a Release 9.0 configuration with a mrouter port configured on the BVPLS and IGMP snooping disabled on the I-VPLS, the active CPM/CFM might have
become unstable.
When booting a Release 9.0 configuration file with a mrouter port configured on the
B-VPLS and IGMP snooping enabled on the B-VPLS, the standby CPM/CFM might
have become unstable.
To avoid this type of instability, the mrouter port configuration should have been removed
before doing an admin-save on the Release 9.0 build, then rebooted with the Release
10.0.R1 build. This issue has been resolved. [133825-MA]
WiFi Offload and

Aggregation
Application
Assurance
The order in which IOMs/IMMs/XCMs came online when the flood-time was activated in
a B-VPLS affected the flooding of broadcast frames from an I-VPLS to B-VPLS. This
IGMP general query messages received in SPB B-VPLS could in some cases get
duplicated into multiple general query messages. This issue has been resolved. [149999MI]
In Release 10.0.R5 and higher, when a High-Availability CPM switchover occurred, the
APN information of a GTP session would not have been displayed anymore in the
CLI/SNMP output. However, the GTP session would have kept working correctly. This
In Release 10.0.R4 and 10.0.R5, the 7750 WLAN-GW would reply to gratuitous ARP
messages (not DAD ARPs). While not specified by RFC 5227, some devices treated this as
an error and immediately stopped the DHCP session by sending a DHCP decline message.
If the WLAN-GW configuration under the subscriber-management CLI context was the
only configuration under that context, then it would incorrectly not have appeared in the
admin-save or display-config outputs. This issue has been resolved. [145883-MI]
The combination in a WiFi-offload setup of soft-GRE, RADIUS proxy-cache and

persistence would have caused a memory leak and would have blocked a lease state when a
RADIUS re-authentication was received with a NAS-IP-Address attribute. Operators using
this combination were advised not to upgrade to Release 10.0.R5 and to use Release
10.0.R4 until Release 10.0.R7 was available. A workaround was to disable persistence in
combinations with short lease times. This issue has been resolved. [146361-MA]
The length field of the UDP header was incorrect for GTP-U packets sent from the WLANGW. This issue has been resolved. [148008-MA]
RADIUS proxy cached the authentication state of a subscriber and used it to authorize
subsequent DHCP messages. If the RADIUS proxy cache was populated with an empty
user-name, the subsequent DHCP message could have triggered a High-Availability
switchover. The workaround was to let the RADIUS server reject Access-Requests with no
user-name present. This issue has been resolved. [148858-MA]
In certain scenarios, the treatment of an active SIP string collection used for improvements
to the rtp performance measurement feature could lead to an alarm being generated
(dpiSipGetClassificationString: Cannot get string field: type 16 buffer 0x0). This issue has
been resolved. [88035, 136163-MI]
303
Resolved Issues
304
If there was insufficient payload in the first HTTP response packet containing the HTTP
response status code to conclude classification, app-qos-policy entries with an action of
http-redirect would not be applied. This issue has been resolved. [136236-MI]
App-filters that used the operators lt and gt for matching server-port values would
positively match all server-port values regardless of the configured value. The workaround
was to use the range operator (for example, use server-port eq range 0 199 instead of
server-port lt 200). This issue has been resolved. [136861-MI]
Under flow resource exhaustion conditions, deletion of a subscriber with active flows may
have caused the MS-ISA card to reboot. This issue has been resolved. It is always
recommended as best practice in AA enabled networks to properly dimension the network
and monitor the number of in-use flow resources per MS-ISA using the "flow-table-highwmark" in order to avoid running out of flow resources and take the appropriate action to
limit the flow resource usage (to be under 80%), by adding MS-ISA cards if possible or
otherwise limiting traffic load. [141042-MA]
When using SNMP to add an aarp-interface to a service, if an invalid interface index was
used in the SNMP set, the active CPM would reboot. This issue has been resolved.
[145157-MA]
If a node configured with multiple primary isa-aa cards and a transit-ip-policy or transitprefix-policy was rebooted, any subscribers added to the transit policy after rebooting
would remain pending and traffic would only pass on the parent context. This only
occurred when the transit policy had no transit subscribers configured while the node was
booting (i.e., no static transits and no persistency configured). This issue might have also
appeared when performing a manual load-balance. The workaround was to remove and reapply the app-profile to the parent SAP/spoke. This issue has been resolved. [145367-MI]
Hexadecimal and binary values for app-filter server-port and app-qos-policy src-port and
dst-port were not accepted as valid entries. This issue has been resolved. [147196-MI]
When using the AA off-line mirror feature, traffic was not diverted to the AA group unless
the AA group was the first and only group configured in the system. This issue has been
The application profile was not displayed by the show service id sap/sdp command for
Ipipe SAP/SDP. This issue has been resolved. [150217-MI]
When cflowd RTP performance was enabled under specific RTCP-XR traffic conditions,
the ISA-AA might have rebooted. This issue has been resolved. [150236-MA]
When the TLS session ID/Ticket pool was exhausted, the next TLS session processed that
required a session ID/Ticket buffer and contained a string that matched an app-filter entry
might have caused the MS-ISA to reboot. This would not have occurred if the stringcollection buffer pool was exhausted first, which is an expected network behavior. This
PPP
When an MLPPPoX bundle that terminated on LNS contained multiple PPP links, some
out-of-order MLPPP fragments might have been discarded on ingress. This issue has been
GTP
GTP peer path management was not supported. The router replied to incoming echo
requests, but did not generate any echo requests. This issue has been resolved. [142716MA]
Resolved Issues
Cflowd
Defining a DSCP value for Cflowd within the sgt-qos configuration will no longer cause
the IP header checksum on Cflowd packets to become corrupt. [151193-MA]
BFD
BFD sessions on a VSM interface that are configured with short timers will no longer
bounce after a High-Availability switchover. This issue has been resolved. [90599-MA]
Single-hop centralized and cpm-np BFD sessions will now reject packets received on an
incorrect interface and/or with an IP TTL lower than 255. [130285-MA]
In rare cases, a BFD session configured on a routed VPLS interface might have remained
down when the service was brought administratively up. The workaround was to re-add the
BFD session or to toggle (shutdown/no shutdown) the interface. This issue has been
If there were multiple static routes configured to use the same IP next-hop and BFD was
used to monitor the reachability to that next-hop, the BFD session to the next-hop address
might not have been removed when all of the static routes were removed from the
configuration. This issue has been resolved. [140339-MA]
If BFD was enabled on two static routes with the same prefix but different preferences, a
BFD session could have been wrongly created after a High-Availability CPM/CFM
switchover for the static route with the lower preference. [143775-MI]
If one of the ETH-CFM tests was done while an FDB entry existed for the chassis MAC
which was of type OAM, all response packets were re-directed to OAM and the ETH-CFM
tests would have timed out. This entry could have been created as part of running the
following OAM commands: cpe-ping, mac-ping, mac-trace, or mfib-ping. This packet loss
would have cleared after five (5) minutes when the OAM entry was aged-out of the FDB
table. This issue has been resolved. [92103-MI]
The TOS field of a received MPLS echo request packet is preserved into the MPLS echo
reply packet by the responder node. When an MPLS echo reply packet is generated in
CPM/CFM and is forwarded to the outgoing interface, the packet is queued in the egress
network queue corresponding to the forwarding class and the profile parameter values
determined by the classification of the echo request packet, which is being replied to, at the
incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings
on the outgoing interface. The TOS byte is not modified. This applies to lsp-ping, lsp-trace,
p2mp-lsp-ping, p2mp-lsp-trace, vccv-ping, and vccv-trace. [101801-MI]
Y.17131 tests no longer fail if there is transit node in a B-VPLS with a VMEP defined.
[134436-MI]
OAM P2MP SSM ping detail did not return the OSPF RID of the responder, instead
returning the system ID instead. This issue has been resolved. [137360-MI]
If an LLDP received PortID subtype had a value of one (1) (interfaceAlias), the port ID
was displayed in a hexadecimal string instead of an ASCII stream. This issue has been
Ethernet CFM MEPs with CCM enabled will no longer stop sending CCM messages to
each other when both endpoint nodes are rebooted at the same time. [139460-MI]
The OAM p2mp-lsp-trace command generated test packets that were 4 bytes larger than in
previous releases because it used a DDMAP TLV (RFC 6424) instead of a DSMAP TLV
(RFC4379) inside the MPLS-ECHO-REQUEST messages. This issue has been resolved.
[140856-MI]
OAM
305
Known Issues
IPv6 pings will now no longer count duplicates when the ICMP sequence number wraps
around at a value of 65K. [144992-MI]
The size option of an MPLS echo request packet now consistently includes the IP header
but not the label stack for lsp-ping, lsp-trace, p2mp-lsp-ping, p2mp-lsp-trace, vccv-ping,
and vccv-trace. The echo request pay-load is padded with zeroes to the specified size. Note
that an OAM command is not failed if the user entered a size lower than the minimum
required to build the packet for the echo request message. The payload is automatically
padded to meet the minimum size. [146389-MI]
An OAM lsp-trace will no longer return DSMappingMismatched if the LSP traverses more
than one (1) hop and the network interfaces have dot1q-etypes configured. [149271-MI]
Reception of ETH-CFM packets with a size larger than 2048 bytes could have resulted in
an active CPM or CFM reset. This issue has been resolved. [154239-MA]
Known Issues
Following are specific technical issues that exist in Release 11.0.R20 of SR OS. Please also
consult Known Limitations on page 183 as some known issues may have been moved to that
section.
Note:
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
CLI
306
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 a CMA/MDA clear. [109738-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]
On very rare occasions, on the 7950 XRS-16c/20, when an SFM is inserted or after a clear
sfm command, the SFM may not have been displayed as equipped in the show sfm CLI
command output for up to a minute. [152947-MI]
On some CPMs on the 7750 SR-12e platform, the management port traffic LED blinking
may cause the Power LEDs to blink as well. [176890-MI]
The system incorrectly allows an admin save operation initiated by a user to be aborted if
another user initiates another admin save from another session. [79185-MI]
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]
Known Issues
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]
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-MI]
Special characters (\s, \d, \w) do not work with pipe/match functions. [100089-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]
A CLI rollback 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]
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 will cause the pasted content to
be overwritten. [126371-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]
Line triggered FCS errors on POS ports may incorrectly result in Ingress Pchip error
alarms. [76053-MI]
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]
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]
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 CPUprotection policy (if desired) should be applied at the tunnel interface level instead of at the
tunnel interface SAP level. [133148-MI]
Traps are no longer sent after the SNMP log is removed and recreated for an snmp-trapgroup that has the replay option configured. [162559-MI]
The transmit (TX) laser of a GigE SFP will remain on regardless of the administrative state
of the port if an operational SFP (Link up) is swapped with a defective SFP (e.g., an SFP
that is unable to be brought up due to bad checksum). To disable the laser, a known
functioning SFP must be inserted. [170027-MI]
On an iom2-20g, IPv4 and IPv6 transit traffic is not counted in the MIB objects
vRtrIfTxBytes and vRtrIfTxPkts of VRtrIfStatsExtEntry. [192987-MI]
If a ToD time-range is deleted without previously deleting all of the configuration

parameters within it, the tmnxPeriodicTimeRangeParmsTable may be left with a stale
307
Known Issues
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]
308
Default log-id 99 or log-id 100 should not be deleted and then re-created without
specifying a log destination; otherwise, this action can result in an invalid configuration to
memory 0 after two CPM/CFM High-Availability switchovers. Saving this invalid
configuration can result in a failure to execute the configuration after a node reboot.
[216517-MA]
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-MI]
ATM
When a local outage occurs in a service with a SAP on an ATM-encapsulated channel, the
ATM channel will transmit F5 RDI cells. If a High-Availability switchover is performed,
the channel will stop sending RDIs and the far-end will think the SAP is up. This only
affects ASAP MDAs on the 7710 SR and does not affect Apipe services, which send AIS
instead of RDI. [133215-MI]
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]
LAG
When uBFD is configured on a LAG, where LACP and bfd-on-distributing-only are also
provisioned, and the uBFD session fails on the primary port but the physical link remains
up, depending on LACP and BFD timer settings, Layer-3 protocol hello messages might
continue to be sent on the primary port instead of moving to another LAG member port.
This issue can result in protocol adjacencies to flap after their hello timer expires. [218559MA]
IGMP
A MIB walk or GET-NEXT of the vRtrPimNgGrpSrcHostEntryTable can result in a loop

when more than one entry is populated. [154205-MI]
MLPPP
If an MLPPP bundle with more than one (1) link has a magic-number set and all links in the
bundle are looped back, a link may not become active when it is removed from the loopedback state. To resolve this situation and to allow the link to become active, shut down the
bundle and toggle (on/off) 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 cosmetic issue. [89341-MI]
If all APS ports are active on either the working or protect router with a highly-scaled MCAPS configuration including MLPPP BPGrps and that router reboots, some PPP links may
Known Issues
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]
Management
The system may not correctly count the number of failed SNMPv3 authentication attempts
in the event-control log. [64537-MI]
SNMP replay events may not function properly for replay functionality with multiple traptargets 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
time-stamp 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]
Using an SNMP walk or GET-NEXT for a newly created SNMP view may cause a HighAvailability switchover. The workaround is to configure the default excluded OID trees for
the new SNMP view, similar to view iso when executing info detail. [97589-MI]
SNMP traps are not forwarded when overwriting or modifying existing trap-target in both
the base and VPRN context. [177129-MI]
When a master local DHCP server grants an IP address that has just been released, the
following false positive alarm may be generated on the standby failover local DHCP
server: BNDUPD message could not be processed for DHCP lease * -- reason:
hostConflict. [177704-MI]
When referring to an authentication policy and the following conditions are met, reauthentication is incorrectly triggered for each renew packet:
DHCP
IS-IS
DHCP option vendor-specific-option pool-name is used
DHCP packets arrive with no Option 82. [194197-MA]
When a DHCP relay is configured with relay-proxy release-update-src-ip and

gi-address ip-address src-ip-addr, a locally-generated unicast DHCP RELEASE message
incorrectly uses the client IP address as the source IP address instead of the gi-address.
[203125-MI]
When IID TLV is enabled on an IS-IS instance, the router can form an adjacency with a
router that does not send IID TLV. This could lead to routing issues if another interface
belonging to that instance forms adjacencies on other instances. IID TLV should not be
configured if non multi-instance-capable routers are part of the same routing domain.
[130612-MI]
309
Known Issues
BGP
310
When used in combination with ECMP, the command show router isis lfa-coverage may
provide incorrect results. [142527-MI]
When overload max-metric is configured under IS-IS, internal routes are still reachable
through the overloaded IS, 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]
The IS-IS overload timer is incorrectly restarted after a Major ISSU. [173200-MI]
The system may keep sending an LSP with zero (0) lifetime if it receives an PSNP packet
for an LSP that is no longer present in the IS-IS database. [178018-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. [180227-MI]
When the unicast-import-disable CLI option is applied to IS-IS MT-ID 2 (IPv6 unicast),
new routes are blocked from the RTM, but routes that existed before the command was
applied are not removed from the RTM. The unicast-import-disable CLI option should not
be used for MT-IDs 2, 3 or 4. [181566-MI]
When IS-IS packet debug is enabled, packets may not always appear in the same order in
the debug output as the order in which they were processed if the time between these
packets is very short. [189998-MI]
Moving a system IP address from one node to another (without doing a shutdown/no
shutdown on IS-IS) can result in a CPM/CFM High-Availability switchover when a CSPF
LSP is enabled to the system IP address that was moved. [218249-MA]
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 BGP peer is shut down when more than one (1) AIGP attribute is received. This was not
the case in releases prior to Release 11.0.R4. The peer is now shut down unless the updatefault-tolerance flag is set. [151844-MI]
Inter-AS Option B and C are not supported between a confederations member ASes.
[157071-MI]
The BGP route selected based on the next-hop cost may not be the best if the same prefix is
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 be selected if a metric change
results in the metric for the next-hop to be greater for P1 and P2 than P3. [211251-MA]
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 occurs where the
configuration is not always translated correctly into the new syntax. For example, alwayscompare-med zero is incorrectly changed into always-compare-med strict-as zero and
therefore results in different operational behavior. [213264-MA]
Known Issues
MPLS/RSVP
In some specific IS-IS multi-level topologies, CSPF may, in rare occasions, calculate an
incorrect path through Level-1 if the system interface IP address is the IS-IS router-ID and
the system interface is configured as Level-2 only. [102537-MI]
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 TE database. [146593-MI]
When the Point-of-Local Repair (PLR) node is in the egress LER node and the outgoing
interface of the bypass LSP is unnumbered, it is required that the user assigns to the
interface a borrowed IP address that is different from the system interface. If not, the
bypass LSP will not come up. [148779-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 shutdown, then RTM
lookup will fail and the message may get dropped. [153707-MI]
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
Traffic using mVPN with S-PMSI LSPs may not be forwarded while the IOM is Soft
Reset, including when performing Minor or Major ISSU. [161884-MA]
The value of LDP graceful restart state is always capable, even when the remote side did
not signal that it is capable of performing graceful restart. [79430-MI]
LDP Path MTU Discovery is not working 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]
311
Known Issues
312
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 administrative state
must be toggled. [149930-MI]
BFD sessions with a non-local ipAddress as the destination (i.e., CentralBfd sessions) are
not able to set up when there is an unnumbered link on the path. [161275-MI]
When performing Major ISSU to Release 11.0 from a prior release, an LDP session to a
peer LSR will not bounce and as such, the new LDP-overload-protection capability TLV
will not be signaled. If LDP runs out of data path or control plane resources, it will use the
base graceful handling capability instead of the enhanced graceful handling capability until
such a time the LDP session bounces. [163266-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/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]
When graceful restart timers are newly configured, timer information is not updated on
active sessions. New timers can be applied by operationally toggling the session.
[169756-MI]
IP Multicast
When creating an IPv6-only interface, an Interface interface-name is not operational

message may appear in the event logs even though the interface is up and running.
[124576-MI]
PIM
PIM in an mVPN on the egress DR does not switch traffic from the (*,G) to the (S,G) tree
if protocol-protection is enabled and PIM is not enabled on the ingress network interface.
The workaround is to enable PIM on all network interfaces. [150674-MI]
In some 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 shortestpath tree have the same IPv6 link-local address, then the router will be unable to send RTPprune messages. [152125-MI]
In dual-homing PE scenarios where the path from the active source-PE to customer RP
fails and recovers, a customers channel (S,G) entry may remain programmed on the PEs
VRF even if the receiver leaves the group. [152632-MI]
Egress multicast traffic may be sent out twice (duplicated) on ports of newly-provisioned
imm3-40gb-qspf, imm12-10gb-sf+ and imm1-100gb-cfp cards if this traffic ingresses on
ports of an IOM1/IOM2 card. This can happen in the following scenarios: mVPN with PIM
enabled and base-instance PIM when the outgoing interface is a spoke-SDP-based
interface. The recovery procedure is to reset the standby CPM and then perform a CPM
switchover. Refer to TA 13-0754 for more details. [158937-MA]
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 a 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]
Known Issues
Filter Policies
Services General
Subscriber
Management
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].
Removing a filter that has a default-action deny from a SAP or an interface may cause a
very small number of packets to 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, the speed at which some
configuration updates to these filters are performed may be degraded, especially during
large configuration changes using long filter match-lists, or large embedded filters. This
configuration update speed degradation does not impact the data-path performance of the
line card. [161389-MI]
Configuration rollback may fail when rolling back configuration changes on filters with
entries overwriting embedded filters 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-MI]
Filter logs used in IP filters and cpm-filters (IOM/IMM/XCM and CPM) will display the IP
headers when IP packets destined to the node come in over igp-shortcut tunnels.
[182994-MI]
uRPF and interface statistics may not be correct after an event such as a clear of the
statistics, clear card or switchover. [150500-MI]
At the creation time of a pseudowire capture-SAP, the pseudowire capture-SAP MTU is

incorrectly not validated against the configured service-mtu. Afterwards, changing the
service-mtu can result in the pseudowire capture-SAP going operationally down when
pseudowire MTU is too small. [209996-MI]
When a RADIUS CoA message triggers the change of both sub-profile and sla-profile, a
RADIUS Accounting-Stop message is generated for the subscriber. The Accounting-Stop
message does not include the old sub-profile name, but the new sub-profile name from the
CoA message. [94758-MI]
Downgrading to Release 9.0.R6 or later in a dual-homed setup may result in a HighAvailability switchover if a DHCP host with an auto-generated subscriber-id was present
on the chassis running Release 11.0, and this host was synchronized back via MCS to the
chassis now running Release 9.0.R6 or higher, and eventually cleared or released.
[132735-MA]
In case a QinQ capture-SAP has a port inner Ethernet type value configured different from
the default value 0x8100, and authentication-policy uses as access method pap-chap,
the PPPoE PADO message is incorrectly sent out of the MSAP with the default inner ether-
313
Known Issues
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]
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-MI]
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]
VPLS
VPRN/2547
Setting up a Diameter peer TCP connection via VPRN is only supported with the default
TCP port 3868. [186325-MI]
When a node experiences a high rate of DHCP overrides, some of them may fail, causing a
memory leak in the IP Stack and Subscriber Mgmt pools. Over time, this can cause the
active CPM/CFM to run out of memory, which can be recovered by performing a HighAvailability switchover. [209325-MA]
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 BPDUtranslation is enabled on the service and STP BPDUs are received over P2MP leaf, they are
dropped as Bad BPDUs. [134168-MI]
A Routed-VPLS service does not support Multicast-VLAN-Registration (MVR). When

allow-ip-int-binding is already enabled in the VPLS service, configuring mvr fromvpls 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-binding is
currently not blocked and can result in a failure to execute the config file after a node
reboot. [163006-MI]
When restrict-protected-src alarm-only is configured with the auto-learn-mac-protect

command, this causes the moving MAC to be learned on the other SAP. [173657-MI]
Executing the show service fdb-mac command simultaneously on two (2) different CLI
sessions may cause a harmless unusual error event Slot A:
smgrSendTlsMacQueryAgeMesg: Malformed IOM response !. [178886-MI]
Ping requests generated from a local VRF or from a CPE entering that VRF cannot reach a
local interface in the Global Routing Table (GRT) that was leaked into that VRF.
[92328-MI]
314
Known Issues
A CE-originated route may still be advertised to MP-BGP peers when it is deleted from the
VRF route table and there is a less-preferred prefix that becomes active in the VRF route
table, even if it should have been rejected by the VRF export policy. To withdraw the CEoriginated route, the VRF export policy must be removed then added, or the VRF export
policy has to be modified to allow and then deny the less-preferred route. [212815-MI]
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 ongoing results in invalid tms-interface statistics. When this error occurs, issuing
the command again when the ISA-TMS TMS Health Information status is up will clean
the statistics properly. [124650-MI]
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 are
dropped due to ingress check when the paths become divergent. [152048-MI]
Configuring via SNMP OID svcEpipePbbBvplsDstMacName without providing a valid

value for OIDs svcEpipePbbBvplsSvcId and svcEpipePbbSvcISID will result in a
CPM/CFM switchover. [211873-MA]
In some cases, clearing video interface statistics can cause the statistics to incorrectly show
a higher number of Tx FCC Replies than a number of Rx FCC Requests. [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]
If WiFi UE mobility between access points (APs) regularly fails, displaying the following
next drop reason in DHCP debug traces: Problem: There is currently another transaction
active for this lease state, then subscriber-management persistency must be disabled.
[195056-MI]
The WLAN-GW may reply to Gratuitous ARP requests when data mobility is enabled,
resulting in a connection delay for certain UE types. [196835-MA]
When a nat-group is in administrative state inService but operational state outOfService,

all NAT routes can still incorrectly be part of the route-table. This issue is only present
when prefix 0.0.0.0/0 is part of the configured NAT inside destination prefixes.
[181925-MI]
Currently, dynamic ports are always reserved, even if only deterministic port blocks have
been reserved via configuration. [195357-MI]
Video
WiFi Offload and

Aggregation
NAT
315
Known Issues
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]
Removing the NAT inside node using the no nat CLI command in the presence of
active deterministic classic LSN prefixes may result in the following traces. It is advisable
to remove all deterministic prefixes before removing the NAT inside node to avoid these
traces:
-
[018 m 07/09/15 15:32:52.004] A:TELNETS-1395:BB:bbNatVrtrDelete This Vrtr

entry still has active deterministic prefixes RCC_TELNET_StartSession>RCC_TELNETD_CreateSession->RCC_TASK_Readline>RCC_TASK_ProcessCmd->RCC_DB_Process_CLI->DB_ParseEngine>DB_ExecuteHandlers->DB_ExecuteHandlersHelper->DB_ExecuteHandler>DB_ExecuteHandlerDispatcher->DB_CallRealHandler>DB_ExecuteLegacyHandlerNoCoarLock->cliConfigServiceVprnNoNat>configRouterNatDelete->sia_tmnxNatVrtrEntrySet->bbNatVrtrDelete
[018 m 07/09/15 15:32:53.097] B:redData_0:BB:bbNatVrtrDelete This Vrtr entry

still has active deterministic prefixes redDataMsgProcessTask>redDoDataProcWork->redProcessMsgs->redProcessMsg>sia_tmnxNatVrtrEntrySet->bbNatVrtrDelete [206572-MI]
Unconfiguring a deterministic prefix with several thousands of deterministic maps may

cause the MS-ISA to reboot. [208698-MA]
L2-aware NAT policies can currently be configured to allow block-limit greater than one
(1). This is not supported. L2-aware NAT policy can only have default block-limit of one
(1). Even if a higher block-limit is configured, it will not take effect. [211949-MI]
On scaled configurations with many static port forward entries present, some of the
MS-ISA cards may take a very long time to become active after a node reboot.
[215131-MA]
Under unexpected SIP traffic conditions, an internal resource may be freed twice, resulting
in a benign error message. [179269-MI]
Under unexpected fragmented GREv1 traffic conditions, benign trace errors may be seen.
[212589-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 are incorrectly timing 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]
Configured DSCP to Forwarding Class (FC) mapping in the config>router>sgt-qos context

is not respected for self-generated ICMP and ICMPv6 packets. [92244-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-
Application
Assurance
316
Known Issues
CFM tests may experience some probe packet loss upon switchover during the Boot
Environment Synchronization stage. [92500-MI]
Operators that opt to change the default values for dot1q-etype or qinq-etype will not
be able to use primary-VLAN functionality. [154756-MI]
When lsp-trace is originated on a BGP IPv4 label 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-MI]
To execute mtrace and mstat with protocol-protection enabled (config>security>cpuprotection), IGMP must be enabled on the incoming interfaces. [160402-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]
lsp-trace of a BGP labeled route with the DDMAP TLV option fails at the egress ASBR if
multi-hop eBGP is used between ASBR nodes. [166209-MI]
If a port is brought operationally down due to excessive CRC errors or internal errors,
ETH-CFM still sends CCM packets on the port indicating that the port MEP was up. For
the Layer-2 network, this can lead to blackholing user traffic. This issue only occurs for
sub-second CCM-enabled port MEPs. [213293-MA]
Document Part Number: 93-0446-20 V11.0.R20

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 2015 Alcatel-Lucent. All rights reserved
*93-0446-20 V11.0.R20*
93-0446-20 V11.0.R20
317
Known Issues
318

SR OS 11.0.R20 Software Release Notes

Î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 11.0.R20 Software Release Notes

Încărcat de

Drepturi de autor:

Formate disponibile

SR OS 11.0.

Release Notes Organization

Release 11.0.R20 Documentation Set on page 4

Release 11.0.R20 Supported Hardware on page 5

New Features in 11.0.R20 on page 20

New Features in 11.0.R19 on page 20

New Features in 11.0.R18 on page 21

New Features in 11.0.R17 on page 21

New Features in 11.0.R16 on page 21

New Features in 11.0.R15 on page 21

New Features in 11.0.R14 on page 22

New Features in 11.0.R13 on page 22

New Features in 11.0.R12 on page 22

New Features in 11.0.R11 on page 22

New Features in 11.0.R10 on page 22

New Features in 11.0.R9 on page 23

New Features in 11.0.R8 on page 23

New Features in 11.0.R7 on page 23

Release Notes Organization

New Features in 11.0.R6 on page 24

New Features in 11.0.R5 on page 26

New Features in 11.0.R4 on page 29

New Features in 11.0.R3 on page 43

New Features in 11.0.R2 on page 44

New Features in 11.0.R1 on page 45

Quality of Service on page 73

Application Assurance Services on page 87

Unsupported Features in 7950 XRS on page 89

Unsupported Features in 7750 SR-12e on page 90

Unsupported Features in 7750 SR-c4 and SR-c12 on page 91

Unsupported Features in 7450 ESS on page 91

Unsupported Features in 7710 SR on page 92

Release 11.0.R20 on page 93

Release 11.0.R19 on page 94

Release 11.0.R18 on page 96

Release 11.0.R17 on page 96

Release 11.0.R16 on page 97

Release 11.0.R15 on page 97

Release 11.0.R14 on page 98

Release 11.0.R13 on page 98

Release 11.0.R12 on page 99

Release 11.0.R11 on page 101

Release 11.0.R10 on page 101

Release 11.0.R9 on page 102

Release 11.0.R8 on page 103

Release 11.0.R7 on page 105

Release 11.0.R6 on page 106

Release 11.0.R5 on page 108

Release 11.0.R4 on page 111

Release 11.0.R3 on page 119

Release 11.0.R2 on page 121

SR OS 11.0.R20 Software Release Notes

Release Notes Organization

Release 11.0.R1 on page 121

Usage Notes on page 139

Software Upgrade Procedures on page 156

Software Upgrade Notes on page 156

AA Signatures Upgrade Procedure on page 162

ISSU Upgrade Procedure on page 166

Standard Software Upgrade Procedure on page 180

Known Limitations on page 183

Resolved Issues on page 222

Resolved in 11.0.R20 on page 222