SR OS 11.0.R20 Software release notes

7/23/2019 SR OS 11.0.R20 Software release notes

http://slidepdf.com/reader/full/sr-os-110r20-software-release-notes 1/318

Alcatel-Lucent 1

SR OS 11.0.R20

DEC-02-2015

*93-0446-20V11.0.R20*

93-0446-20 V11.0.R20

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:

• 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














SR OS 11.0.R20

SOFTWARE RELEASE NOTES




2 SR OS 11.0.R20 Software Release Notes




• New Features in 11.0.R3 on page 43• New Features in 11.0.R2 on page 44


- 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 3


• 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




- Resolved in 11.0.R16 on page 235- Resolved in 11.0.R15 on page 236















• 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 docu-mentation 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-LucentModel # 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-LucentModel # Description

7750 SR-1 7750 SR-1 chassis (AC and DC)



7750 SR-12e 7750 SR-12e chassis

7750 SR-c4 7750 SR-c4 chassis (AC and DC)


7450 ESS-1 7450 ESS-1 chassis (AC and DC)


7450 ESS-6v 7450 ESS-6v chassis (vertical ESS-6)









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-LucentPart # 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


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)


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

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





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 7x50 12-port 10G Ethernet SFP+ IMM - L2HQ

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

3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMMa

- L2HQ

3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMMa

- 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


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

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





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 7x50 12-port 10GE FP3 SFP+ IMMa - L2HQ

3HE07159AA 7x50 1-port 100GE FP3 CFP IMMa - L3HQ

3HE07159BA 7x50 1-port 100GE FP3 CFP IMMa - L3BQ

3HE07159CA 7x50 1-port 100GE FP3 CFP IMMa - L2HQ

3HE07166AA 7750 SR-12e SF/CPM4-12e (SR-12e only)

3HE07167AA 7750 SR-12e Mini-SFM4-12e (SR-12e only)3HE07303AA 7x50 2-port 100GE FP3 CFP IMMa - L3HQ

3HE07303BA 7x50 2-port 100GE FP3 CFP IMMa - L3BQ

3HE07303CA 7x50 2-port 100GE FP3 CFP IMMa - L2HQ

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 7x50 20-port 10GE FP3 SFP+ IMMa - L3HQ

3HE07305BA 7x50 20-port 10GE FP3 SFP+ IMMa - L3BQ

3HE07305CA 7x50 20-port 10GE FP3 SFP+ IMMa - L2HQ

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

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





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


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)



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)


3HE04743AAAB 7x50 12-port 10G Ethernet SFP+ IMM - L3HQ

3HE05053AAAB 7x50 1-port 100G Ethernet CFP IMM- L3HQ

3HE05055AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM -

L3HQ



SR (Continued)

Alcatel-Lucent

Part # Description

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-






3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM -

L2HQ

3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM -

L3BQ



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





3HE05950AA 7450 ESS-12 SF/CPM4 (ESS-12)

3HE05951AA 7450 ESS-7 SF/CPM4 (ESS-7)

3HE06318AA 7750 Multicore-CPU IOM3-XP



3HE06326AA 7x50 48-port GE Multicore-CPU SFP IMM - L3HQ

3HE06326BA 7x50 48-port GE Multicore-CPU SFP IMM - L3BQ

3HE06326CA 7x50 48-port GE Multicore-CPU SFP IMM - L2HQ







3HE06798AA 7750 1-port 40GE DWDM Tunable IMM - L3HQ

3HE06798BA 7750 1-port 40GE DWDM Tunable IMM - L3BQ

3HE06798CA 7750 1-port 40GE DWDM Tunable IMM - L2HQ3HE07158AA 7x50 12-port 10GE FP3 SFP+ IMM - L3HQ

3HE07158BA 7x50 12-port 10GE FP3 SFP+ IMM - L3BQ

3HE07158CA 7x50 12-port 10GE FP3 SFP+ IMM - L2HQ

3HE07159AA 7x50 1-port 100GE FP3 CFP IMM - L3HQ

3HE07159BA 7x50 1-port 100GE FP3 CFP IMM - L3BQ

TABLE 5. SFM, IOM and IMM Line Cards Supported in 7450 ESS (Continued)






3HE07159CA 7x50 1-port 100GE FP3 CFP IMM - L2HQ




3HE07304AA 7x50 6-port 40GE FP3 QSFP IMM - L3HQ

3HE07304BA 7x50 6-port 40GE FP3 QSFP IMM - L3BQ

3HE07304CA 7x50 6-port 40GE FP3 QSFP IMM - L2HQ

3HE07305AA 7x50 20-port 10GE FP3 SFP+ IMM - L3HQ



3HE08019AA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L3HQ3HE08019BA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L3BQ

3HE08019CA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L2HQ

3HE08020AA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L3HQ

3HE08020BA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L3BQ

3HE08020CA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L2HQ

3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3HQ

3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3BQ

3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L2HQ

3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3HQ

3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3BQ

3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L2HQ

3HE08426AA 7750 SR IOM3-XP-C

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 7x50 48-port GE MultiCore SFP IMM - L2HQ

TABLE 5. SFM, IOM and IMM Line Cards Supported in 7450 ESS (Continued)






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 6. 7710 SR Line Cards


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)

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


S R- c 1 2

S R- c 4

S R-1

i om-2 0 g- b

i om2 -2 0 g

i om 3 -x p / - b / - c

3HE00021AA 60-port 10/100TX MDA - mini-RJ21 Y Y Y Y Y Y

3HE00023AA 20-port 100FX MDA - SFP Y Y Y Y Y Y

3HE00025AA 5-port GigE MDA - SFP Y Y Y

3HE00026AA 10-port GigE MDA - SFP Y Y Y3HE00030AA 1-port 10GBASE-LW/LR MDA w/

optics - Simplex SC

Y Y Y Y

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

optics - Simplex SC

Y Y Y Y

3HE00032AA 8-port OC-3c/STM-1c MDA - SFP Y Y Y Y Y Y

3HE00033AA 16-port OC-3c/STM-1c MDA - SFP Y Y Y Y







3HE00043AA 2-port OC-48c/STM-16c MDA - SFP Y Y Y Y Y Y


3HE00048AA 1-port OC-192c/STM-64c MDA w/SR-

1/I-64.1 optic - Simplex SC

Y Y Y Y

3HE00049AA 1-port OC-192c/STM-64c MDA w/IR-

2/S-64.2 optic - Simplex SC

Y Y Y Y

3HE00071AA 4-port ATM OC-12c/STM-4c MDA -

SFP

Y Y Y Y Y Y

3HE00074AA 16-port ATM OC-3c/STM-1c MDA -

SFP

Y Y Y Y

3HE00101AB 20-port 10/100/1000TX MDA - RJ45 Y Y Y Y

3HE00707AA 2-port 10GBASE MDA - XFP Y Y Y Y

3HE00708AA 20-port GigE MDA - SFP Y Y Y Y

3HE00709AA 1-port OC-192c/STM-64c MDA w/LR-

2/L-64.2 optic - Simplex SC

Y Y Y Y

3HE00710AA 1-port 10GBASE-ZW/ZR MDA w/

optics - Simplex SC

Y Y Y Y

3HE00714AA 1-port 10GBASE MDA - XFP Y Y Y Y

3HE01020AA 8-port Channelized DS1/E1 CMA -

RJ48c

Y Y

3HE01021AA 4-port DS3/E3 CMA – 1.0/2.3 Y Y

3HE01022AA 8-port 10/100TX Ethernet CMA - RJ45 Y Y

3HE01023AA 1-port GigE CMA - SFP Y Y

3HE01197AA 7750 SR Versatile Services Module

(VSM)

Y Y Y Y

3HE01364AA 4-port Channelized OC-3/STM-1 (DS0)

ASAP MDA - SFP

Y Y Y Y

3HE01615AA 5-port GigE MDA - SFP Rev B Y Y Y Y

3HE01616AA 10-port GigE MDA - SFP Rev B Y Y Y Y

3HE02021AA 1-port 10GBASE + 10-port GIGE MDA Y Y Y Y

3HE02185AA 2-port OC-3c/STM-1c/OC-12c/STM-4c

CMA - SFP

Y Y

3HE02499AA 1-port Channelized OC-12/STM-4

ASAP MDA

Y Y Y Y

3HE02500AA 12-port Channelized DS3/E3 ASAP

MDA

Y Y Y Y

TABLE 8. MDAs, CMAs, and ISAs Supported in 7750 SR (Continued)


S R- c 1 2

S R

- c 4

S R

-1

i om-2 0 g- b

i om2 -2 0 g

i om 3 -x

p / - b / - c





3HE02501AA 4-port Channelized DS3/E3 ASAP

MDA

Y Y Y Y

3HE03077AA 1-port Channelized OC-3/STM-1 CES

CMA

Y Y

3HE03078AA 1-port Channelized OC-3/STM-1 CES

MDA

Y Y

3HE03079AA 7750 SR 4-port CH OC3-1/STM-1 CES

SFP MDA

Y Y Y Y

3HE03609AA 1-port GE CMA-XP SFP Y Y

3HE03610AA 5-port GE CMA-XP SFP Y Y

3HE03611AA 7750 SR 10-port GE - XP - SFP MDA Y Y Y Y Y Y

3HE03612AA 7750 SR 20-port GE - XP - SFP MDA Y Y Y Y Y Y

3HE03613AA 7750 SR 20-port GE - XP - Copper/TX

MDA

Y Y Y Y Y Y

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

MDA

Y Y Y Y Y Y


MDA

Y Y Y Y

3HE04179AA 7750 SR 10GBASE Tunable ZW/R

MDA

Y Y Y Y

3HE04272AA 7750 SR 1-port OC-12/STM-4 CESMDA Y Y Y Y


MDA

Y Y Y Y Y Y

3HE04922AA 7750 SR / 7450 ESS Multiservice ISAa Y Y Y Y Y

3HE05142AA 7750 SR / 7450 ESS Multiservice ISA-E

(no encryption)a

Y Y Y Y Y

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

MDA - mini-RJ21

Y

3HE05942AA 7750 SR / 7450 ESS Versatile Services

Module XP (VSM-CCA-XP)

Y Y Y Y

3HE05943AA 7750 SR 16-port OC-3/12c STM-1/4c

POS MDA - SFP Rev B

Y Y Y Y Y Y

3HE05944AA 7750 SR 16-port ATM OC-3c/STM-1c

MDA - SFP Rev B

Y Y Y Y


MDA - SFP Rev B

Y Y Y Y Y Y

3HE05946AA 7750 SR 4-port OC-48c/STM-16c POS

MDA - SFP Rev B

Y Y Y Y Y Y



S R- c 1 2

S R

- c 4

S R

-1

i om-2 0 g- b

i om2 -2 0 g

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-





3HE05947AA 7750 SR 2-port OC-192/STM-64 -XP -

XFP MDA

Y Y Y Y

3HE06432AA 7750 SR 10-port GE SFP HS-MDAv2 Y

3HE06521AA 2-port OC-3c/STM-1c/OC-12c/STM-4c

CMA - SFP Rev B

Y Y

3HE07282AA 7750 SR 2-port 10GE XFP + 12-port

GE SFP -XP MDA

Y

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

MDA

Y Y Y

3HE08220AA 8-port Channelized DS1/E1 CMA RevB

Y Y

a. Refer to Usage Notes on page 139 for specifics.Table 6

TABLE 9. MDAs and ISAs Supported in 7450 ESS


E S S -1

i om-2 0 g- b

i om 3 -x p / - b / - c

3HE00021AA 7750 SR 60-port 10/100TX MDA -

mini-RJ21a

Y

3HE00023AA 7750 SR 20-port 100FX MDA - SFPa Y

3HE00030AA 7750 SR 1-port 10GBASE-LW/LR

MDA w/ optics - Simplex SCa

Y

3HE00031AA 7750 SR 1-port 10GBASE-EW/ER


Y

3HE00033AA 7750 SR 16-port OC-3c/STM-1c MDA -

SFPa

Y

3HE00037AA 7750 SR 8-port OC-12c/STM-4c MDA -

SFPa

Y

3HE00038AA 7750 SR 16-port OC-12c/STM-4c MDA

- SFPa

Y


- SFPa

Y


- SFPa

Y



S R- c 1 2

S R

- c 4

S R

-1

i om-2 0 g- b

i om2 -2 0 g

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





3HE00048AA 7750 SR 1-port OC-192c/STM-64c

MDA w/SR-1/I-64.1 optic - Simplex

SCa

Y


MDA w/IR-2/S-64.2 optic - Simplex

SCa

Y


MDA - SFP b

Y


MDA - SFP b

Y

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

- RJ45a

Y

3HE00230AA 60-port 10/100TX MDA - mini-RJ21 Y Y Y

3HE00231AA 20-port 100FX MDA - SFP Y Y Y

3HE00232AA 10-port GigE MDA - SFP Y Y

3HE00233AA 20-port GigE MDA - SFP Y Y Y

3HE00234AB 20-port 10/100/1000TX MDA - RJ45 Y Y Y

3HE00235AA 1-port 10GBASE-LW/LR MDA w/

optics - Simplex SC

Y Y Y

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

optics - Simplex SC

Y Y Y

3HE00237AA 16-port OC-3c/STM-1c MDA - SFP Y Y Y





3HE00317AA 2-port 10GBASE MDA - XFP Y Y Y

3HE00707AA 7750 SR 2-port 10GBASE MDA - XFPa Y

3HE00708AA 7750 SR 20-port GigE MDA - SFPa Y


MDA w/LR-2/L-64.2 optic - Simplex

SCa

Y

3HE00710AA 7750 SR 1-port 10GBASE-ZW/ZR


Y

3HE00714AA 7750 SR 1-port 10GBASE MDA - XFPa Y

TABLE 9. MDAs and ISAs Supported in 7450 ESS (Continued)


E S

S -1

i om-2 0 g- b

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





3HE01173AA 1-port 10GBASE-ZW/ZR MDA w/

optics - Simplex SC

Y Y Y

3HE01197AA 7750 SR Versatile Services Module

(VSM)a

Y

3HE01198AA 7450 ESS Versatile Services Module

(VSM)

Y Y Y

3HE01364AA 7750 SR 4-port Channelized OC-

3/STM-1 (DS0) ASAP MDA - SFP b

Y

3HE01532AA 10-port GigE MDA - SFP Rev B Y Y Y

3HE01616AA 7750 SR 10-port GigE MDA - SFP Rev

Ba

Y

3HE01617AA 1-port 10GBASE MDA - XFP Y Y Y

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

GIGE MDAa

Y

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

GigE MDA

Y Y Y


12/STM-4 ASAP MDA b

Y

3HE02500AA 7750 SR 12-port Channelized DS3/E3

ASAP MDA b

Y

3HE02501AA 7750 SR 4-port Channelized DS3/E3

ASAP MDA b

Y


3/STM-1 CES MDA b

Y

3HE03079AA 7750 SR 4-port CH OC3-1/STM-1 CES

SFP MDA b

Y

3HE03611AA 7750 SR 10-port GE - XP - SFP MDAa Y

3HE03612AA 7750 SR 20-port GE - XP - SFP MDAa Y

3HE03613AA 7750 SR 20-port GE - XP - Copper/TX

MDAa

Y

3HE03614AA 7450 ESS 10-port GE - XP - SFP MDA Y Y Y

3HE03615AA 7450 ESS 20-port GE - XP - SFP MDA Y Y Y

3HE03616AA 7450 ESS 20-port GE - XP - Copper/TX

MDA

Y Y Y


MDAa

Y



E S

S -1

i om-2 0 g- b

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-






MDAa

Y

3HE03687AA 7450 ESS 2-port 10GBASE - XP - XFP

MDA

Y Y Y

3HE03688AA 7450 ESS 4-port 10GBASE - XP - XFP

MDA

Y Y Y

3HE04179AA 7750 SR 10GBASE Tunable ZW/R

MDAa

Y

3HE04181AA 7450 ESS 10GBASE Tunable ZW/R

MDA

Y Y Y

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

MDA b

Y

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

MDA

Y Y Y


MDAa

Y

3HE04922AA 7750 SR / 7450 ESS Multiservice ISAc Y Y

3HE05142AA 7750 SR / 7450 ESS Multiservice ISA-E

(no encryption)c

Y Y

3HE05159AA 7450 SR 48-port 10/100/1000 - XP

MDA - mini-RJ21

Y

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

MDA - mini-RJ21a

Y

3HE05942AA 7750 SR / 7450 ESS Versatile Services

Module XP (VSM-CCA-XP)

Y Y Y

3HE05943AA 7750 SR 16-port OC-3/12c STM-1/4c

POS MDA - SFP Rev Ba

Y


MDA-SFP Rev B b

Y


MDA - SFP Rev B b

Y

3HE05946AA 7750 SR 4-port OC-48c/STM-16c POS

MDA - SFP Rev Ba

Y

3HE05947AA 7750 SR 2-port OC-192/STM-64 -XP -

XFP MDAb

Y

3HE06382AA 7450 ESS 16-port OC-3/12c STM-1/4c

POS MDA - SFP Rev B

Y Y Y



E S

S -1

i om-2 0 g- b

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-





3HE06383AA 7450 ESS 4-port OC-48c/STM-16c POS

MDA - SFP Rev B

Y Y Y

3HE06432AA 7750 SR 10-port GE SFP HS-MDAv2a Y

3HE06434AA 7450 ESS 10-port GE SFP HS-MDAv2 Y

3HE07282AA 7750 SR 2-port 10GE XFP + 12-port

GE SFP -XP MDAa

Y

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

GE SFP -XP MDA

Y

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

MDAa

Y

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

MDA

Y Y

a. Supported only with 7750 SR IOM3-XP in the 7450 ESS chassis, with or withoutmixed-mode.

b. Supported only with 7750 SR IOM3-XP in the mixed-mode-enabled 7450 ESSchassis.

c. Refer to Usage Notes on page 139 for specifics.

TABLE 10. 7710 SR MDAs and CMAs


3HE00021AA 60-port 10/100TX MDA - mini-RJ21

3HE00023AA 20-port 100FX MDA - SFP

3HE00025AA 5-port GigE MDA - SFP

3HE00032AA 8-port OC-3c/STM-1c MDA - SFP


3HE00071AA 4-port ATM OC-12c/STM-4c MDA - SFP

3HE00101AB 20-port 10/100/1000TX MDA - RJ45


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 5-port GigE MDA - SFP Rev B



E S

S -1

i om-2 0 g- b

i om 3 -x

p / - b / - c

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



New Features in 11.0.R20



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

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

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


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 MDA3HE05945AA 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

TABLE 10. 7710 SR MDAs and CMAs (Continued)


















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 the7750 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.





1 PPS Outpu t

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.











The following section describes the new feature added since Release 11.0.R10 to theRelease 11.0.R11 of SR OS.

48-por t GE Rev-C

IMM

SR OS now supports the new variant of 48-port GE Multicore-CPU SFP IMM (IMM48-GE-

SFP-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.











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 SR-

7/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-XP-

B. 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:





• 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 levelAlong 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

The 40-port 10GE SFP+ XMA for 7950 XRS now supports WAN-PHY mode.

10-port 10GE SFP+

+ 20-port GE SFP

Multicore CPU-

based IMM and 3-

por t 40GE QSFP +

20-port GE SFP

Multicore CPU-

based IMM

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 ofthe 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.





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 IPv6-

Multicast 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 translatedthrough 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 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-pool-mode on the card. This feature is supported on FP2- and higher-based line cards.

IKEv2 Remote

Access Tunnels

IPsec IKEv2 remote-access tunnel is now supported in Release 11.0.R6 and includes the

following features:





• Authentication methods:

- Pre-Shared-Key RADIUS

- Certificate RADIUS

- EAP/EAP-Only — The system acts only as an EAP authenticator; the actual EAPauthentication 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 peer’s 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.

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 CPMor 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

Authent ication 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 tochange their selected time source.

Auto -Creat ion 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.





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.

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.

Extensions to LSP

Trace to Support

LSP Stitch ing and

LSP Hierarchy

Release 11.0.R5 extends the use of the LSP trace tool to cover the following scenarios:

• 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.

OSPF Alternate

ABR

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 haschanged; 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 fo r 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 business-

critical 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 draft-

ietf-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 length-

related errors.

BGP GracefulRestart Suppor t

for Notifications

Release 11.0.R5 enhances the BGP Graceful Restart implementation in SR OS so that it can beused 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





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:

• 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

6-Port 40GE

QSFP+ C-XMA

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 6-

port 40GE C-XMA offers six (6) QSFP ports, compatible with all Alcatel-Lucent family QSFP

modules (QSFPs not included).

7750 SR-c12 CFM-

XP-B

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 Fil ters

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 canthen 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 fullyestablished. 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





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 IP-

in-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

Accoun ting-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 Framed-

IPv6-Route

support and

Framed-Routeenhancements

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 gateway-

address [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





• configure subscriber-mgmt radius-accounting-policy include-radius-attribute framed-ipv6-

route

802.3ah and ISSU In Release 11.0.R4, support has been added to allow the operator to enable a vendor-specificgrace 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 CCM-

Enabled 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 sub-

second 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 CCM-

interval-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 filt er 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 sourceand destination

ports match

criterion in CPM

IPv4 and IPv6 fil ter

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 itsaction if a TCP/UDP packet matches the port value or values on either the source port field, the

destination port field, or both.

Auto -generat ion of

filter-policy

address prefix

match lists for

Line Card ACL

IPv4 and IPv6 fil ter 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.

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 auto-

populated with the BGP neighbor address prefixes changes and, in turn, filter policies that usethose 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:

• Initial Registration

• Key Pair Update

• Certificate Update

• Polling

Support fo r RIP on

7950 XRS

The same capability and scaling for RIP on the 7750 SR are now supported on 7950 XRS.

BGP-AD for R-

VPLS

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 automaticallydiscovering the endpoints of a Layer-2 VPN, offering an operational model similar to that of an

IP-VPN.

Unnumbered

Interface Suppor t

in LDP

Release 11.0.R4 allows LDP to establish Hello adjacencies and to resolve unicast and multicast

FECs over unnumbered LDP interfaces.





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

ResourceExhaustion

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 andto 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.





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 differentupstream 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 next-

hop. 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.





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 Deterministi c

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 L ink

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 IS-

IS

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

Profi le (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 asan 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:





• 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, MC-

APS 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 ESS-

6/6v/7/12 with IOM3/IMM or higher, but with the following restrictions:

• Supported on Ethernet ports only

• Requires SF/CPM3 for full-scaled BFD

• Requires network chassis mode D

Local pool

management for

PPPoX and PPPoE

SLAAC hosts

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.





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 Adjustmentper VportIn Release 11.0.R4, modification of a Vport bandwidth based on received IGMP joins/leaves inscenarios 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.

Determinis tic DS-

Lite

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.





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:

• 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

DHCPv4/v6 Server

Multi-Homing

Enhancements

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 un-

interrupted 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 ofthe existing path protection mechanisms (SRRP/MC-LAG) in the access part of the net-

work. Otherwise, the IP address duplication may occur in cases where DHCP or PPP cli-

ents 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 theSRRP/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.





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 dupli-cation, the logical intercommunication link between the two nodes must be well-protected

with multiple physical paths between the two nodes.

Automat ic

Creation of RSVP

Mesh and One-

Hop 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 re-

evaluates 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 provisioningmodel 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 router-

id 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 auto-

LSP 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.





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 Suppor t

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:

• Soft pre-emption of LSP path using unnumbered interface

• Inter-area LSP

• RSVP refresh reduction on an unnumbered interface.

Enhancements to

Admin-Group

Support on

Bypass

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 multi-

homing 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 transportand 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-





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 MC-

LAG.

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/VPRNServices

PW SAPs provide the ability to apply access QoS policies to a pseudowire at an MPLS network-

facing 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 T-

LDP 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 interface-

name sap pw- pw-sap-id [:[s-tag[.c-tag]]]

This feature also introduces a new config>service>sdp>binding>pw-port>egress>shaper CLInode, 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

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 byconfiguring 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 Certif icate

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 template-

set l2-ip.




SFM-X20-B Release 11.0.R3 introduces SFM-X20-B, a new variant of SFM-X20 for 7950 XRS-20.





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 fully-

programmable 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 On-

Demand 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 system-

id) 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.






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 12-

port 10G IMM, 20-

por t 10G IMM, 1-

por t 100G + 10-port 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 (PM-QPSK)

• Software selectable wavelength tunable across 89 DWDM channels (50Ghz spacing)

• Feature alignment with 10G and 40G Serial MDA/IMMs

• Enhanced FEC (EFEC)





• 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)


• Supported in 7750 SR-7/12/12e and 7450 ESS-7/12 chassis equipped with SF/CPM4 only.



license(s).

IMPORTANT NOTE: Impedance panels must be purchased and installed in all systems inwhich 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.


1-port 100GE CFP

+ 10-port 10GE

SFP+ MultiCore-

CPU-based IMM

Release 11.0.R1 introduces the 1-port 100GE CFP + 10-port 10GE SFP+ MultiCore-CPU-

based IMM to the Alcatel-Lucent’s 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


• 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 thefeatures used. Contact your Alcatel-Lucent representative for the appropriate application

license(s).


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.






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:

• 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

WAN-PHY Support

for 7950 XRS 20-

port 10G C-XMA

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.

MS-ISA on 7450

Mixed-Mode

In Release 11.0.R1, the following are now supported on the MS-ISA on the 7450 ESS in mixed-

mode:

• 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,





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, high-

performance, high-availability services and supports specialized service-aware application

processing, advanced quality of service (QoS), and a comprehensive range of Ethernet andmulti-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 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

http://-/?-

http://-/?-





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 MultiCore-CPU 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).


which an IMM is used. These impedance panels provide highly efficient air flow in support of

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 + 12-

Port 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.





• 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).

12-Port GE MDA-

XP

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).

2-Port OC-

192/STM-64 MDA-

XP

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 node’s 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.





This capability is new in Release 11.0.R1 for the following assemblies and only in 100BASE-

TX and 1000BASE-T modes. It is not supported on ports in 10BASE-T mode.

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 matchcriterion 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-generat ion of

filter-policy match

criteria for CPM

IPv4 and IPv6 filter

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 router’s 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 neighboraddress 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 LAG-

based 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-link-

hashing only for LAG-based L3 IES/VPRN SAPs or network interfaces, excluding ng-mVPN

multicast.

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





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 fo r 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:

• 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)

IEEE 1588 Default

Profile

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.

1588 Port-Based

Timestamping

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.

The MDAs must reside in one of the following IOMs to allow for PTP port-based timestamping:

ServicesThe 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

TABLE 12. PTP Port-Based Timestamping Supported IMMs and MDAs







3HE03611AA 7750 SR 10-port GE - XP - SFP MDA

3HE03612AA 7750 SR 20-port GE - XP - SFP MDAa

a. Capability available on ports one (1) through 11 inclusive.

3HE03612AA 7750 SR 2-port 10GBASE - XP – XFP MDA3HE03686AA 7750 SR 4-port 10GBASE - XP – XFP MDA

3HE04274AA 7750 SR 1-port 10GBASE - XP – XFP MDA

3HE03614AA 7450 ESS 10-port GE - XP - SFP MDA

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

TABLE 13. PTP Port-Based Timestamping Supported IOMs





3HE03620AA 7450 ESS IOM3-XP (iom3-xp)





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

suppor t 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 Sender-

only/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

Administ rat ive

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 admingroup. 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

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:





• 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).

BGP VPWS 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 BGP-

signaled 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 describedin 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 R-

IVPLS 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 R-

IVPLS 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 (AS’s). Release 11.0.R1

adds Inter-AS mVPN Option B support and allows operators to improve upon the Inter-AS





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 N-

to-1 mapping of

ATM VPI/VCI to

ATM Pseudowi re

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 thenetwork. 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

In Release 11.0.R1, Enhanced Subscriber Management (ESM) is supported on all FP3-based

Multicore-CPU IMMs.

NAT Support for

10x MS-

ISA/chassis

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

Authent ication

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 defaultsThe 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 (IPoEonly). Note that username manipulation for PPPoE hosts is performed via authentication-

policy.

• 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.





• 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 constructwithin 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

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

Subscriber-

Interface

Address ing 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 Routed-

CO 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.





CDN Result Code

Overwrite on LNS

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:

• 4—Call 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”.

Inter WLAN-GW

Redundancy and

Mobility

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 WLAN-

GW receives traffic on the MS-ISA, and based on the configuration, triggers RADIUSauthentication 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 L2-

aware NAT and subscriber creation via data triggered authentication as described above.

“ Migrant” user support on WLAN-

GW

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 portal-

authentication, 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 “pre-

authenticated” 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 “local-

breakout” 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 theuser. 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 access-

accept. 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 RADIUS-

proxy 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 por t

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.





• 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 haveany static port forwards left).

ANCP ANCP in Release 11.0.R1 supports database persistency, RADIUS ANCP (access-loop-

information) 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 BNG’s 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. Thiscommand, 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 relayenhancements

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 group-

interface 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.

Uniform RADIUSserver

configuration

To align RADIUS server configuration and functionality for different applications, withRelease 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-server-

policy-name

• configure subscriber-mgmt radius-accounting-policy name radius-server-policy radius-

server-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 radius-

server-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 acct-

on-off command is removed from a radius-server-policy, or when it is user-triggered with a

CLI command.

• 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.

PPP

enhancements

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: Remote-

ID/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 issupported.

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.





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 isactivated/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 subscriberservice 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

The following RADIUS enhancements are new to Release 11.0.R1:

• Attribute value limits have changed for “[1] User-Name” (253 chars.), “[2] User-

Password” (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.

IPv6 Router

Adver ti sement

option for DNS

configuration

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] Alc-

Ipv6-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 Layer-

2 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-Rule-

Shared” 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 pre-

configured 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

entriesenhancement

Release 11.0.R1 offers a new RADIUS attribute, [26-6527-159] Alc-Ascend-Data-Filter-Host-

Spec, which enables the insertion of subscriber-host-specific filter entries into the active ip-

filter 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 newattribute 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.





• 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 “debugradius” 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 port-

block allocation is non-deterministic and as such, it will be logged. Similarly, all static port

forwards are logged.





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 [secondary-

pool 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)

Release 11.0.R1 adds the support to pre-authenticate a PPPoE subscriber with a separate

RADIUS server to get LLID (logical representation for subscriber’s physical access line) before

normal subscriber authentication is performed. The authentication policy for the pre-

authentication 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 NAS-

Port-Id. The LLID is returned in calling-station-ID (RADIUS attribute 31) from the pre-

authentication 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.

IPv6 support fo r

HTTP redirection

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.

Encapsulation Tag

Range Support in

LUDB

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





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 sync’d using multi-

chassis 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 amessaging 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 group-

interface (without SAPs) on the same subscriber-interface with the parameter 'oper-up-while-

empty' 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-Tunnel-

Connection/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:• 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.

RADIUS Route

Download

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.

MLPPPoX in

Subscriber

Management

Context

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 subscriber-

interfaces”. 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 Multi -

Chassis 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).

IGMPSynchronization in

Routed CO

Environment

Synchronization of subscriber IGMP states between redundant BNG nodes will ensurecontinuous 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). Inaddition, 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,





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: Large-

Scale 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





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 Soft-

GRE) 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 Per-

Tunnel 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:

Appl ication

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 per-

SAP lockout policy contains lockout related configuration. Lockout is supported for static SAPs





(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, thecontexts 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-subscriber-

string, 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:

• To release LSN resources immediately after the BNG subscriber is terminated—BNG

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 subscribers—With 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 (standard RADIUS attribute)

• Calling-station-id (standard RADIUS attribute)

• 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 port-

forwards, obtain information about existing port-forwards and to obtain the outside IP addressfrom 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 adapt-

QoS 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 link-

map-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

Aggregat ion

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 LAG’s ports reside on instead of per each LAG port.





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 oregress 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 theexisting 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/IPPrecedence-Based

PW Egress Packet

Re-Classification

This feature, introduced in Release 10.0.R4, allows the user to perform egress re-classificationof 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 spoke-

SDP 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 Suppor t

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

UnnumberedInterfaces

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 beenavailable 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 (IPv4-

only 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

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.

Routing Policy

Subroutines

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.





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 list’s 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 Lis t

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 list’s 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 LineCard Filter (ACL)

policy system

scale

Release 11.0.R1 introduces improved Line-Card-Filter (ACL) policy scale for IPv4, IPv6 andMAC 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

Resoluti on 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 policyhas 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.





VPRN Support for

BGP

Confederations

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-AS’s of the confederation. A VPRN that belongs to

a confederation cannot import or export VPN-IP routes.

BGP FlowSpec

Enhancements

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 Rou te

Indirect Next-HopOption

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 fo r 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 IPv4Routes

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 pre-computation 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.





Associate

Communities with

Static and

Aggregate Routes

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.

OSPF LSA

Filtering

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).

BGP AIGP Metric

At tr ibute

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.

Multicast only

Fast-Reroute

(MoFRR) for native

IP networks

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 oningress 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-basedline cards.

This feature affects the following statistics:

• 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-per-

Prefix 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 Tunnel ing

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 Multi-

active Tunnel-

group

Release 10.0.R5 and higher add GRE tunnel support on multi-active tunnel-groups. Multi-

active 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 inter-

chassis 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.





IP FRR Using

Loop-Free

Al ternate fo r IPv6

and VPN-IPV6

Prefixes in BothIS-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.

This feature is supported on 7950 XRS, on 7750 SR-7/12 in chassis mode D, on 7450 ESS-

6/6v/7/12 in chassis mode D with or without mixed-mode, and on 7750 SR-c4/12.

IP FRR support f or

IGP Shortcuts wi th

IS-IS Prefi xes

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.

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 IGPshortcuts 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 Suppor t

with BGP Next-

Hop 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 SupportFor 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-FreeAlternate (LFA) backup to expand the coverage of LDP Fast-Reroute (FRR) capability. 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 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 link-

protect.

BGP Resolving

Next-Hop to BGP

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 fo r

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.

communi t y “abc” member s “t arget : 1234: 111” “t arget : 1234: 222” “t arget : 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.

communi t y “abc” expressi on “t arget : 1234: 111 AND t arget : 1234: 222 AND t ar -get : 1234: 333”

communi t y “def ” expr essi on “t arget : 1234: 111 OR t arget : 1234: 222”

communi t y “ghi ” express i on “t arget : 1234: 1. 1 AND NOT t arget : 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 Appli ed 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 todeploy 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.





This feature is available on the 7950 XRS, 7750 SR-c4/c12, 7750 SR-7/12 and the 7450 ESS-

7/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 Shortcu t

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

Administ rat ive

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, theoperational 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





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. TheHello 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 reductionfactor 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 Hold-

Time 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 Suppor tin 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.





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 fo r IGP

Shortcuts with

OSPF Prefixes

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 NHtype, 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 SR-

7/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-idsystem | 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.

Automat ic ABR

Selection for Inter-

Area 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

suppor t 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 connectedto 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.





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

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.

Admin Group

Support on Facility

Bypass Backup

LSP

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, andmixed-mode on 7450 ESS. It is also supported on the 7950 XRS, 7750 SR-12e, and 7750 SR-

c4/c12 platforms.





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

• Single–node 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 toa 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 applica-

tion/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





high sampling rates. Using the AA comprehensive flow sampled Cflowd mechanism, oper-

ators can target (or exclude) certain applications (or application groups) for sampling, pro-

viding 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 usage-

based 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 transitSubscribers

Starting with Release 10.0.R4, Seen-IP transit subscriber notification provides RADIUSAccounting-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 Release 11.0.R1 adds the support for IPv6 to the existing TWAMP server functionality.

ETH-CFM Primary

VLAN

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 ITU-

T 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)



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:

• 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 mixed-

mode1:

• 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.



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 IOM3-

XP when mixed-mode is enabled.)

Unsupported Features in 7710 SR

The following features are not supported on the 7710 SR platform:

• 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.

Release 11.0.R20

System • 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 wasactually 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]

IS-IS • 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

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 spreadsheetat 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.

http://-/?-

https://infoproducts.alcatel-lucent.com/aces/cgi-bin/au_doc_list.pl

http://-/?-




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 includedthose 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 re-

established while the MS-ISAs are rebooting on the standby chassis. [208268]

Appl ication

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

Hardware • 10 GBase tunable DWDM SFP+ (low-power 1.5 watts MSA-compliant) is now supportedon 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]

Appl ication Assurance

• Release 11.0 R19 supports a new version of the isa-aa.tim file that enables new andupdated 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.

• 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

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 communi-

cation protocol introduced by Google in Chrome

using UDP instead of TCP to transport

HTTP/HTTPs content.

SPDY new Provides detection of unencrypted SPDY over TCP.

Symantec Backup new Provides detection of Symantec Backup Exec over

TCP.

Taobao new Provides detection of Taobao over HTTP, SPDY

and TLS.

TLS_HTTP2 new Provides detection HTTP2 traffic over TLS. Prior

to the introduction of this new protocol HTTP2

encrypted flows were classified as TLS.

WhatsApp_RTP new Provides detection of WhatsApp voice traffic over

RTP.

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.



Enhancements


generated by Chrome browser to Google servers now uses this protocol; therefore, it is rec-

ommended 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 theopening 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

HW/Platform • 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]

System • 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 standbyCPM 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 tothe 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]

Appl ication

Assurance

• Release 11.0.R17 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




Release 11.0.R16


Release 11.0.R15

System • Release 11.0.R15 reintroduces statistics collection for IES and VPRN interfaces on iom-

20g-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]

Appl ication

Assurance







DTLS new Provides detection of DTLS 1.0, DTLS 1.2, DTLS

X.509 certificate subject common and organization

name string matching and DTLS session resump-

tion using session ID.

Flow Export new Provides detection of NetFlow v5/v8/v9, IPFIX

over UDP and sFlow v5.

Snapchat new Provides detection of Snapchat over TLS.

QQ updated Provides improved detection of QQ traffic over

HTTP and TCP.

Weixin updated Provides improved detection of WeChat traffic over

HTTP and TCP.



OpenVPN updated Provides detection of Hotspot Shield over UDP and

TCP.



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]

Appl ication

Assurance





Release 11.0.R13

HW/Platform • 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 lattercan 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, iom3-

xp-c, imm48-1gb-tx, imm48-1gb-sfp, imm48-1gb-sfp-b, imm48-1gb-sfp-c, imm4-10gb-

xfp, 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 intervalcan 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


Protocol Status CommentsJustinTv updated Provides detection of only Twitch Video Streaming

(both services belong to the same parent company,

Twitch Interactive)



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 PW-

template 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 BGPVPWS SAP (Epipe only). Fault propagation between a MEP and the BGP update state sig-

naling 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]

Appl ication

Assurance





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 client-

cipher-list is used when the SR OS node is acting as the SSH client, and the server-cipher-

list 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]



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



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 addressfamilies are present (previously, only IPv4 and IPv6 address families were considered),

which can improve mVPN route convergence time on control-plane route reflectors.

[175404]

Appl ication

Assurance





OAM • 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]



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 upload-

ing over TCP

QQ updated Provides improved detection of QQ video/audio

communication between two QQ devices over TCPSOCKS updated Provides improved detection of SOCKS in the situ-

ation where the UDP traffic starts late

Weixin updated Provides detection of WeChat file transfers over

TCP which were being detected as HTTP



Enhancements


Release 11.0.R11


Release 11.0.R10

HW/Platform • 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 toRelease 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.

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 over-

load 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 • 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]

PIM • 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]



Enhancements


Appl ication

Assurance





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 sessionterminates 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 ppp-

policy. RADIUS authentication fails when no default PAP password is configured and the

client provides no password in the Authenticate-Request. [177343]

Appl ication

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




Advanced Direct Con-

nect

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 TCPand UDP

OpenVPN updated Resolves the issue where BFD traffic was being

detected as OpenVPN



CCcam new Provides detection of CCcam satellite card sharing

over TCP



Enhancements


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 tunnel-

group 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 route-

table”. [174516]

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 trafficthat 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




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 theASAP 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-per-

mac) has been increased from 1023 to 8191. [173081]

Appl ication

Assurance

• The HTTP-notification flow selection for HTTP In-Browser-Notification has been

enhanced to support additional types of HTTP flows. [168109]







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 overTCP/UDP, Tango Instant Messaging and Photo

Sharing over TLS and Tango Emoticon, Anima-

tions, 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 inter-

leaved with STUN/TURN traffic

SIP updated Provides improved detection SIP traffic over RTP

SIP updated Provides improved detection of SIP and RTP_SIP

over TLSSteam 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


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 High-

Availability 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>ca- profile>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 TIMETRA-

VRTR-MIB:

- vRtrIfRxPkts and vRtrIfRxBytes—These counters now reflect an aggregate count of

both IPv4 and IPv6 packets

- vRtrIfuRPFCheckFailPkts and vRtrIfuRPFCheckFailBytes—These counters now

reflect an aggregate count of both IPv4 and IPv6 packets

- New IPv4-only versions of the following counters have been added:

- vRtrIfRxV4Pkts and vRtrIfRxV4Bytes

- vRtrIfV4uRPFCheckFailPkts and vRtrIfV4uRPFCheckFailBytes. [167809]

Appl ication

Assurance





uTP updated Provides improved detection of uTP traffic which

was being detected as DHT

Yahoo Messenger updated Provides improved detection of Yahoo Messengerover TCP




RTSP updated Provides improved detection of RTSP streaming

over UDP

SIP updated Provides improved detection of SIP over RTP



Enhancements


Release 11.0.R6

HW/Platform • 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 imm-

2pac-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 non-

recoverable 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 interactive-

authentication”), 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.

IS-IS • 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



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 IDfor 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 theconfigured destination ports. Prior to Release 11.0.R6, only well-known destination ports

were considered. [164829]

WiFi Offload and

Aggregat ion

• Release 11.0.R6 supports GGSN’s/PGW’s returning a different IP address in the session-

create 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]

Appl ication

Assurance



shown in the table below. For a complete list of the Release 11.0 AA identificationcapabilities (protocols and applications), contact your regional support organization.



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 Messen-

ger

updated Provides improved detection of AOL Instance Mes-

senger voice and video chat traffic over TCP and

UDP

Ares updated Provides improved detection of Ares over UDPBBC 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



Enhancements


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]

CLI • 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 file-

url 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]

LAG • 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 Fast-

Reroute (MoFRR).

PIM • Release 11.0.R5 enhances Draft-Rosen mVPN Inter-AS support. Some Ciscoimplementations 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.

TeamSpeak updated Provides improved detection of TeamSpeak over

TCP and UDP

WeChat updated Provides improved detection of WeChat over TCPand HTTP




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:

- ifXEntry

- ifHCInOctets

- ifHCInUcastPkts

- ifHCOutOctets

- ifHCOutUcastPkts

- ifEntry

- ifInOctets

- ifInUcastPkts

- ifInDiscards

- ifOutOctets

- ifOutUcastPkts

- ifOutDiscards. [146878]

IPsec • 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-algsha1|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 intoa 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]



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 identicalFramed-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 next-

hops. [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-before-

break (MBB) the paths away from the node in IS-IS overload state at the time a manual ortimer-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:

- 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.

Appl ication

Assurance





Enhancements




OAM • 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>mpls-

echo-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:



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 traf-

fic 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 SIPSubversion updated Provides improved detection of Subversion over

HTTP

TLS updated Provides improved detection of TLS for asymmetri-

cal flows



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]

• On the XRS-20, the Fan Status LED has the following new behavior starting with Release

11.0.R4:

- 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]

System • 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 ithas 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 CPMand 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



Enhancements


policies). The existing behavior prior to Release 11.0.R4 is preserved with the default “no”

configuration for each new option. [129167]

IPsec • The “debug ipsec” command has been enhanced in Release 11.0.R4 to include decodedoutput 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]

LAG • 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, andSAPs 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 RSVP-

TE provider tunnels, ESM, PW port, and SAPs for L2 services.

• Release 11.0.R1 introduced support for a new LAG adapt-qos mode: distributed include-

egr-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]



Enhancements


• 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]

MPLS • 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]

LDP • 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-MAC-

flush-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-from-

me 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 notincluded, 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 mes-

sage 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 follow-

ing behavior is observed:



Enhancements


- If the ingress and egress bindings are spoke-SDP, the PE will propagate the MAC-

flush 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 PE-

ID 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 B-

VPLS if the send-bvpls-flush command is enabled in the I-VPLS. In the same way, no PE-

ID is added when propagating MAC-flush from a B-VPLS to a I-VPLS when the propa-

gate-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:pol i cer - cont r ol - overr i de [ creat e]

no pol i cer- cont r ol - overr i de max- r ate <r at e> | max

pri ori ty- mbs- t hr eshol ds

mi n- t hr esh- separati on <si ze> [ bytes | ki l obytes] no mi n- t hr esh- separat i on

[no] pr i or i ty <l evel >

mbs- cont r i but i on <si ze> [ bytes | ki l obytes] no mbs-cont r i but i on

The user can also override the policer parameters for network ingress FP queue groups.

The following parameters for policers can be overridden:

conf i g>card>f p>i ngr ess>net work>qgr p>pol i cer - over >pl cr $ [ no] cbs Speci f y CBS overr i de

[ no] mbs Speci f y MBS over r i de

[ no] packet- byte- of* Speci f y packet byte off set [ no] r at e Speci f y r ates ( CI R and PI R) over r i de

[ no] st at- mode Speci f y Stat Mode f or t he pol i cer [ 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]



Enhancements


Subscriber

Management

• 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 receivingrequests 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 all-

zero 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 initiator’s 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]



Enhancements


• Release 11.0.R4 introduces the support for accurate Port-Based Timestamping on Ethernet

Link Aggregation Groups. [160028]

WiFi Offload and Aggregat ion• 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-radius-

policy, 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 Alc-

Wlan-Handover-Ip-Address attribute) and the IP address of the PGW/GGSN (in 3GPP-

GGSN-Address attribute) in access-accept. The presence of the Alc-Wlan-Handover-Ip-

Address 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 forredundancy. [161635]

BGP VPWS • When a local site is operationally down, both the D and CSV bits are now set in the BGP-

VPWS 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.

Appl ication

Assurance

• Release 11.0.R4 allows multiple accounting policies with record type of “custom-record-

aa-sub” to be used simultaneously in a node, such as one policy for business AA records

and another for residential AA records. [148375]



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 recordcontent. App-profile is provided as a configuration option under “config>log>accounting-

policy>custom-record>aa-specific>aa-sub-attributes”. [159700]





OAM • 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]



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 Tra-

versal

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 RTPQVOD 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



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 changeapplies only to regular IES and VPRN interfaces with lease-populate disabled (no lease-

populate) 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 SFM-

X20-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 aCE, 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



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 inthe “3GPP-GPRS-Negotiated-QOS-Profile” attribute, or can be populated from locally-

configured 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]

Appl ication

Assurance


protocol signatures and applications. The new and updated protocols in this release areshown in the table below. For a complete list of the Release 11.0 AA identification




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 Warcraftin-game traffic over TCP.



Enhancements


Release 11.0.R2

HW/Platform • XPL errors will now be reported on ASAP MDAs. [143526]

Appl ication

Assurance





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 tmnxPort-

PhysStateChangeCount. [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]



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.



Enhancements


• 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 bespecified 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-xp-

xfp, 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]

• 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.

CLI • 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-id-

number ][detail]” command. [149321]

System • 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 newshow 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]

IPsec • 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.

Minimum

number ofOperating

APEQs

Maximum

number ofprovisioned

XCMs

6 4

8 7

11 10



Enhancements


• 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 multi-

chassis 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 MC-

IPsec mastership of the local tunnel-group is the same as the state specified by the “to”

parameter, then no switchover will take place. [149348]

Filter Policies • Release 10.0.R7 and higher add fragmentation support to IPv6 ACL filter policies for FP2-

and 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]

IP Multicast • 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]

LAG • 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-linkscale for 40GE- and 100GE-based LAGs (previously limited to 8). A single LAG can serve

up to 3.2 Tbps. [138494]

DHCP • 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]

• Starting with Release 10.0.R4, failover/redundancy is supported in the DHCPv6 Local

Server used for ESM.

OSPF • The base router now includes a new “no-adjacency-check” option to the originate-default-

route 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 originate-

default-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 type-

7 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.

BGP • 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 forwardingtable. Installing an active aggregate route in the forwarding table with a black-hole next-

hop 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 as-

path-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]



Enhancements


• 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 AS-

path 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 beenclosed 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]

MPLS/RSVP • 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 andregardless 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 • 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]

• 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 FP2-

and higher-based line cards.

MPLS/RSVP • 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]

LDP • 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]

Management • 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,



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 astatic 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 tra-

ceroute responses from the base router are supported by default and are not configurable.

[120243]

• 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]

Ingress Multicast

Path Management

• A set of commands introduced in Release 10.0.R4, under “configure>mcast-

management>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 wasreceived, 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:conf i g>ser vi ce>epi pe>spoke- sdp

conf i g>ser vi ce>pw- t empl ate [ no] bl ock- on- peer- f aul t

Def aul t : di sabl ed

When “block-on-peer-fault” is enabled, it blocks Tx direction of a PW when any of the fol-

lowing 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-signaling-

slave. It is not applicable to spoke-SDPs forming part of an MC-LAG or spoke-SDPs in an

endpoint. [129052]

• 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.

Subscriber

Management

• 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]



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 Session-

Timeout, 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-Relative-

Session-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 stan-

dard [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 enhancedwith 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.



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 parame-

ters 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 atwhich 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 de-

allocated). 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



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 multi-

chassis 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 inter-

preted as DHCP lease time as before. However, if both Alc-Lease-Time and session-time-

out 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 ofthe session. However, if Alc-Relative-Session-Timeout VSA is provided, then the session-

timeout is relative to current time at the reception of the VSA. [132694]

• 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] Alc-

RSSI. [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 Access-

Request 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 auto-

generate 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 unique-

sid-per-sap behavior. The “per-msap” configuration is not default in order to be backward-

compatible 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 client’s 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 session-

accounting and host-accounting. Queue-instance-accounting does not follow this new

RADIUS Accounting behavior. [145215]



Enhancements


VPLS • 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 andIGMP 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 asingle 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-ingress-

egress. 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.

NAT • 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 NAT’d,

the resulting IPv4 traffic can be optionally subjected to filtering in order to protect the

control-plane. [122723]



Enhancements


• 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 nat-

group 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-chassisenvironment. [138556]

PPPoE • 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: “max-

sessions-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 preference-

level method is configurable using the new “next-attempt” command. [145092]

Mirroring/Lawful

Intercept (LI)

• 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.

WiFi Aggregation

and Offload

• 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]

Appl ication

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



and updated protocol signatures and applications. The new and updated protocols in thisrelease 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



Enhancements


identification capabilities (protocols and applications), contact your regional support

organization.



release are: Betamax VoIP, CNN Live, DNS, Gnutella, IPSec NAT Traversal, MSCommunicator, 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 (protocolsand applications), contact your regional support organization.







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 stream-

ing 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, con-

trol and track selection over UDP and TCP.

Ustream new Provides detection of Ustream audio/video stream-

ing 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


• 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 HTTP-

redirect 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]

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 ses-

sion 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 head-

ers.

TLS updated Provides improved detection of TLS when TCP

segments are out of order.

TLS updated Provided detection of non-basic ASCII charactersin TLS strings.

TLS updated Provides improved detection of clients using multi-

ple 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.




Enhancements


• 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]

OAM • The p2mp-lsp-ping and p2mp-lsp-trace implementation has been updated to use the newDownstream 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 interconnectVSI 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 ETH-

CCM 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

• 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.

7750 SR-12e 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 SoftwareImage 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.



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.

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:conf i g>i sa# i nf o

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - i psec- gr oup 1 cr eat e

pri mary 1/ 2

no shut down exi t

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

conf i g>car d# i nf o- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

card- t ype i om3- xp

mda 1 mda- t ype m10- 1gb- sf p- b

exi t

mda 2 mda- t ype i sa- i psec

exi t

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 tun-

nel-x.public:y

config>service>vprn>ipsec-interface zzz config>service>vprn>interface zzz tunnel

config>service>vprn>ipsec-if>sap ipsec-

x.private:y

config>service>vprn>if>sap tunnel-x.pri-

vate:y

config>service>vprn>ipsec-if>sap>tun-

nel

config>service>vprn>if>sap>ipsec-tun-

nel



Usage Notes


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -conf i g>servi ce>vpr n# i nf o

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

r out e- di st i ngui sher 100: 300 i nt er f ace "t oPubNet" creat e

address 192. 168. 33. 1/ 24 sap 1/ 1/ 9 cr eat e

exi t exi t

i nt erf ace "publ i c- i psec" creat e

address 192. 168. 44. 1/ 24 sap i psec- 1. publ i c: 100 creat e

exi t

exi t

no shut down- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

conf i g>ser vi ce>vpr n# i nf o

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - i psec

secur i t y- pol i cy 1 creat e

ent r y 10 cr eat e l ocal - i p 192. 168. 99. 1/ 32

r emote- i p any

exi t exi t

exi t

r out e- di st i ngui sher 100: 400 i psec- i nt erf ace "pri vat e- i psec" creat e

sap i psec- 1. pr i vat e: 100 creat e

t unnel "t 1" creat e securi ty- pol i cy 1

l ocal - gat eway- address 192. 168. 44. 99 peer

192. 168. 33. 100 del i ver y- servi ce 300 dynami c- keyi ng

i ke- pol i cy 1

pre- shar ed- key "psk" transform1

exi t

no shut down

exi t exi t

exi t

i nt er f ace "l oop1" creat e address 192. 168. 99. 1/ 32

l oopback

exi t

st ati c- r out e 192. 168. 22. 0/ 24 i psec- t unnel "t 1" no shut down

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

8.0.R4 or later configuration (changes are italicized ):

conf i g>i sa# i nf o- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

tunnel-group 1 create

pri mary 1/ 2

no shut down

exi t- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

conf i g>car d# i nf o

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



Usage Notes


card- t ype i om3- xp mda 1

mda- t ype m10- 1gb- sf p- b

exi t mda 2

mda-type isa-tunnel

exi t

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -conf i g>servi ce>vpr n# i nf o

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

r out e-di st i ngui sher 100: 300 i nt er f ace "t oPubNet " creat e

address 192. 168. 33. 1/ 24

sap 1/ 1/ 9 cr eat e

exi t exi t

i nt er f ace "publ i c- i psec" creat e

address 192. 168. 44. 1/ 24 sap tunnel-1.public:100 create

exi t

exi t no shut down

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

conf i g>ser vi ce>vpr n# i nf o- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i psec

securi t y-pol i cy 1 creat e ent r y 10 cr eat e

l ocal - i p 192. 168. 99. 1/ 32

r emote- i p any exi t

exi t

exi t r out e-di st i ngui sher 100: 400

interface "private-ipsec" tunnel create

sap tunnel-1.private:100 create ipsec-tunnel "t1" create

securi ty- pol i cy 1

l ocal - gat eway- address 192. 168. 44. 99 peer

192. 168. 33. 100 del i ver y- servi ce 300 dynami c- keyi ng

i ke- pol i cy 1

pre- shar ed- key "psk" transform1

exi t

no shut down

exi t exi t

exi t

i nt er f ace "l oop1" creat e address 192. 168. 99. 1/ 32

l oopback

exi t st at i c- r out e 192. 168. 22. 0/ 24 i psec- t unnel "t 1"

no shut down

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



Usage Notes


Mixed-Mode The following table lists the supported 7750 SR MDAs, IOM, and IMMs in 7450 ESS in Mixed-

Mode (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


3HE00021AA 60-port 10/100TX MDA - mini-RJ21

3HE00023AA 20-port 100FX MDA - SFP

3HE00030AA 1-port 10GBASE-LW/LR MDA w/ optics - Simplex SC

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







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



3HE00101AB 20-port 10/100/1000TX MDA - RJ45

3HE00707AA 2-port 10GBASE MDA - XFP


3HE00709AA 1-port OC-192c/STM-64c MDA w/LR-2/L-64.2 optic - Simplex SC3HE00710AA 1-port 10GBASE-ZW/ZR MDA w/ optics - Simplex SC

3HE00714AA 1-port 10GBASE MDA - XFP

3HE01197AA 7750 SR Versatile Services Module (VSM)

3HE01364AA 4-port Channelized OC-3/STM-1 (DS0) ASAP MDA - SFP

3HE01616AA 10-port GigE MDA - SFP Rev B

3HE02021AA 1-port 10GBASE + 10-port GIGE MDA

3HE02499AA 1-port Channelized OC-12/STM-4 ASAP MDA



3HE03078AA 1-port Channelized OC-3/STM-1 CES MDA

3HE03079AA 7750 SR 4-port CH OC3-1/STM-1 CES SFP MDA



3HE03613AA 7750 SR 20-port GE - XP - Copper/TX MDA




Usage Notes





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


3HE04179AA 7750 SR 10GBASE Tunable ZW/R MDA

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


3HE04741AA 7750 SR 5-port 10GE fixed port IOM (IMM)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



3HE05813AA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM -L2HQ

3HE05813BA 7x50 1-port OC-768c/STM-256c OTU3 Long Reach DWDM Tunable IMM -

L3BQ




3HE05895BA 7x50 48-port GE fixed port IOM (IMM) - L3BQ


3HE05896BA 7x50 48-port GE copper port IOM (IMM) - L3BQ





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


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



3HE06326AA 7x50 48-port GE Multicore-CPU SFP IMM - L3HQ

3HE06326BA 7x50 48-port GE Multicore-CPU SFP IMM - L3BQ

3HE06326CA 7x50 48-port GE Multicore-CPU SFP IMM - L2HQ



3HE06430AA 7x50 5-port 10GE fixed port IOM (IMM) - L3HQ3HE06431AA 7x50 8-port 10GE fixed port IOM (IMM) - L3HQ

3HE06432AA 7750 SR 10-port GE SFP HS-MDAv2



3HE06798AA 7750 1-port 40GE DWDM Tunable IMM - L3HQ

3HE06798BA 7750 1-port 40GE DWDM Tunable IMM - L3BQ

3HE06798CA 7750 1-port 40GE DWDM Tunable IMM - L2HQ







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



3HE07303CA 7x50 2-port 100GE FP3 CFP IMM - L2HQ3HE07304AA 7x50 6-port 40GE FP3 QSFP IMM - L3HQ

3HE07304BA 7x50 6-port 40GE FP3 QSFP IMM - L3BQ

3HE07304CA 7x50 6-port 40GE FP3 QSFP IMM - L2HQ





http://-/?-

http://-/?-

http://-/?-

http://-/?-



Usage Notes


MultiserviceIntegrated

Services Adapter

The following tables list IOM support for MS-ISA and MS-ISA-E applications:


3HE08019AA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L3HQ

3HE08019BA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L3BQ

3HE08019CA 7x50 1-port 100GE DWDM Tunable FP3 IMM - L2HQ

3HE08020AA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L3HQ

3HE08020BA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L3BQ

3HE08020CA 7x50 1-port 100GE CFP + 10-port 10GE SFP+ FP3 IMM - L2HQ

3HE08174AA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3HQ

3HE08174BA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L3BQ

3HE08174CA 7x50 10-port 10GE SFP+ + 20-port GE SFP FP3 IMM - L2HQ

3HE08175AA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3HQ3HE08175BA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L3BQ

3HE08175CA 7x50 3-port 40GE QSFP + 20-port GE SFP FP3 IMM - L2HQ

3HE08426AA 7750 SR IOM3-XP-C

3HE09279AA 7x50 48-port GE MultiCore SFP IMM - L3HQ

3HE09279BA 7x50 48-port GE MultiCore SFP IMM - L3BQ

3HE09279CA 7x50 48-port GE MultiCore SFP IMM - L2HQ

a. MS-ISAs and ISA applications using MS-ISAs are not supported in mixed-mode with theexception of Application Assurance, IPsec, NAT and FCC/RET.



TABLE 32. Compatible 7750 SR IOMs for MS-ISA Applications

IOM-20g-b IOM2-20gIOM3-XP/-b/

-c

Application Assurance (isa-aa)aY Y Y

Retransmission and Fast ChannelChange

(Video ISA)

Y Y Y

Video Quality MonitoringY Y Y

Video Dual Stream SelectionY Y Y

Local/Zoned Ad Insertion(Video ISA)

Y Y Y

Tunnel Services, including IPsec

(isa-tunnel)a

N Y b Y b



Usage Notes


BGP VPWS • When a provisioned SDP that is used for a spoke-SDP is shut down or there is a local LSP

failure (causing the spoke-SDP to go down), a BGP-VPWS update will be sent to the

adjacent PE with the CSV bit set to one (1). This, however, does not cause the spoke-SDP,

site or SAP to go down on the adjacent PE. If the adjacent PE is the designated forwarder

of a pair of dual-homed PEs, no designated forwarder failover occurs. The above situation

can result in the designated forwarder being one of the dual-homed PEs but the remote PE

using its pseudowire to the other dual-homed PE.

Upgrading from

7710 SR-c12 to an

7750 SR-c12

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 theconfiguration 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 SR-

c12:

Network Address Translation (isa-bb) N N Y

L2TP LNS Service (isa-bb)

N N Y

WLAN-GW (isa-bb) N N Y

Arbor TMS (isa-tms) N N Y

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-bIOM3-XP/-B/

-C

Application Assurance(isa-aa)

Y Y

Retransmission and FastChannel Change

(Video ISA)

Y Y

TABLE 32. Compatible 7750 SR IOMs for MS-ISA Applications (Continued)



Usage Notes


Compact Flash

Devices

• 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

Appl ication

Assurance

• The isa-aa.tim image is available in the same directory as other .tim images. The image

contains the Application Assurance software used on MS-ISA and the protocol list loaded by the CPM. The Application Assurance software can be upgraded independently of the

SR OS software within a major release of the SR OS.

• When an application-assurance group dual-bucket-bandwidth policer is configured, the

default configuration will cause all packets to be dropped. Ensure that the dual-bucket-

bandwidth policer is configured appropriately. [86311]

• Only properly negotiated TCP sessions are eligible for TCP performance sampling.

• Changes to the TCP performance sampling rates will only affect new traffic flows.

• The bandwidth capacity for an AA-subscriber is equal to the full capacity of the MS-ISA

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 otherMDA 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.

IPsec • IKE traffic should be treated as higher priority than any data plane traffic (like ESP) on the

end-to-end path from a remote IPsec peer to a 7750 SR, which means that appropriate

ingress/egress QoS policy should be configured on the corresponding network facing port

(or SAP) and public tunnel-sap of 7750 SR and any other network forwarding node along

the way.

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



Usage Notes


IPsec

Compatibility

• The following tables list software and hardware tested for compatibility with IPsec

services:

Management • SNMPv3 user authentication and privacy keys in the ‘config>system>security>user user-

name>snmp>authentication’ command must be entered as maximum length strings.

[18314]

• Manual editing of SNMP persistent index files can cause errors in loading the

configuration file. Persistent index files should only be created by the system. [24327]

TCP Authent ication

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:

- 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 entry’s counters to zero. If the counters are required, they should be retrieved

prior to such a configuration change.

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



Usage Notes


• 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.

HW/Platform • SFPs with bad checksums cause traps and log events. The port will be kept operationally

down with SFPs that fail to read or have invalid checksums 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. Third-

party optics are not supported.

System • When creating a new log file on a Compact Flash disk card, the system will check the

amount of free disk space and the amount must be greater than or equal to the lesser of 5.2

MB or 10% of the Compact Flash disk capacity.

• Downgrading from chassis mode C to chassis mode B may require the removal of IPv6

addresses from the BOF configuration. [133960]



Usage Notes


CLI • 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 entriesfrom 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 theworking 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:

- 0-127 is used for keepalive function

- 128-255 is used for differential delay detection.

Keepalive statistics only count echo packets with IDs from 0-127.

• In order to interoperate with other vendors’ MLPPP implementations, the MLPPP sub-layer will accept packets with or without leading zeros in the protocol field even though the

7750 SR, 7450 ESS in mixed-mode and 7710 SR do not advertise the protocol field

compression (PFC) option during LCP negotiation. [25996, 29923]



Usage Notes


Routing • 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 aCFM switchover. [56792, 58891]

IS-IS • The granularity of the IS-IS hold timer is accurate only to within +/- 0.5s, so having a

computed holdtime value of less than 2s may result in adjacencies being randomly

dropped. 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-authentication-

type is set to password for an interface, it is not activated until a key is added at the

interface level. [34256]

IS-IS TE • The protocol sends advertisements with the IS-IS Traffic Engineering (TE) Router ID TLV

when traffic engineering is disabled. [17683]

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]

MPLS/RSVP • The current bypass binding selection logic for Release 7.0 and higher is the following:

For non-Strict environment

a) Manual CSPF disjoint bypass

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 beselected instead.

2) Non-CSPF Manual Bypass will never be selected. [66005]

• The enabling or disabling of Diff-Serv on the system requires that the RSVP and MPLS

protocols be shut down. When first created in Release 7.0 or higher, RSVP and MPLS will

be administratively down. The user must execute the “no shutdown” command for each

protocol once all parameters under both protocols are defined. When saved in the



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.

• 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]

IP Multicast • If an ‘rp static-address’ is configured, the current PIM implementation will install an

implicit deny-all for 224.0.0.0/4. To re-permit this address range, another static entry for

this range must be installed. [38630]

• MoFRR for PIM interfaces should be enabled on a hop-by-hop basis to ensure optimal

MoFRR recovery.

• If auto-rebalancing is enabled, re-balancing when a new path becomes available is

performed for active joins.

• Optimized IP-multicast replication over RSVP-TE spoke-SDPs using configurable

multicast network domains requires all spoke interfaces to be configured exclusively on physical ports, LAG ports, or APS-protected ports. If that is not the case, the default

replication will take place.

• Alcatel-Lucent recommends CPM3 or higher for PIM adjacency scale beyond 1,500.

• To execute mtrace and mstat with protocol-protection enabled (config>security>cpu-

protection), IGMP must be enabled on incoming interfaces. [160402]

QoS • By default, the CBS value of newly-created queues in queue-group policies is zero (0)

percent. Adding queue-groups or other configuration may result in reservation of all

available buffer space (CBS) so that there is no shared buffer space available and queues

with CBS of zero (0) percent will drop traffic. Expedited traffic for newly-created queues

in queue-group policies with default CBS of zero (0) percent may also be lost when there is

congestion of non-expedited traffic. To prevent the loss of traffic, 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 offered-

uncolored 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 commandoutput 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.



Usage Notes


LDP • 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.

Subscriber

Management

• 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 Diameter-

base 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 isdifferent 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. Whenthe 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



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 Auto-

Discovery

• 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.



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.

In the sections below, the following terminology is used:

• Deprecated commands are not flagged as errors upon reading a configuration file withdeprecated 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.

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 all7450 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.





• 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.R1through 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 byentering “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 "port-

forwarding-dyn-block-reservation" should be removed from the NAT configuration when

having a type L2-aware NAT-group configured. More details can be found in TA 13-1007.

[163525]

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 bemanually 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-all-

users”, 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





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 TIMETRA-

TC-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.R1or 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 entryand 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 containsSR 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





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-ingress-

stats” 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

Appl ication

Assurance f rom

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.





Upgrading

Appl ication

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

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 valueadded 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 tothose 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:

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.

Upgrading from

Release 6.1 or

earlier to 11.0.R20

The following note applies to upgrading from SR OS Release 6.1 or lower to SR OS Release

11.0.R20.

Appl ication

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 thisdocument.

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





• 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 valuehigher 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 "remote-

mepid <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 throughRelease 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 MS-

ISAs in 7750 SR-7/12/12e, 7750 SR-c4/c12 and ESS-6/6v/7/12 to a new AA signature load

without upgrading/impacting the router itself:

- When no firmware update is required

If the above criteria does not apply, the Standard Software Upgrade Procedure on page 180must

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.





Step 1 Backup Existing Images and Configu ration Files

New software loads may make modifications to the configuration file which are not compatible

with older versions of the software.

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 fi le 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.

• Use “admi n r edundancy synchr oni ze boot - env” to synchronize the boot

environments between the active and standby CPM/CFMs.

STEP 4 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 “admi n appl i cat i on- assurance upgr ade” to load the new isa-aa image on

the CPM/CFM.

• Use “show appl i cat i on- assur ance ver si on” 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# ver si on

==============================================================================Vers i ons of i sa- aa. t i m i n use

==============================================================================

CPM : Ti MOS- M- 10. 0. R21/ 2 : Ti MOS- M- 10. 0. R1

3/ 2 : Ti MOS- M- 10. 0. R1

==============================================================================

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.





A: Cpm- A# show mda==============================================================================

MDA Summar y

==============================================================================Sl ot MDA Provi si oned Equi pped Admi n Oper at i onal

Mda- t ype Mda- t ype State Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 2 i sa- aa i sa- ms up I SSU/ st andby. . .

3 2 i sa- aa i sa- ms up I SSU/ acti ve

==============================================================================

STEP 5 Reset the MS-ISAs to Load the New Image

The MS-ISAs must now be reset to load the new image.

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 “shut down mda <m>/ <n>” to shut down an MS-ISA

• Use “cl ear mda <m>/ <n>” to reset an MS-ISA

• Use “no shut down mda <m>/ <n>” to enable an MS-ISA

• Use “show appl i cat i on- assur ance ver si on” 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 ApplicationAssurance group with one (1) active and one (1) protecting (standby) MS-ISA.

1. Before reset starts:

A: ALU- ABC>show>app- assur e# versi on

==============================================================================

Vers i ons of i sa- aa. t i m i n use==============================================================================

CPM : Ti MOS-M- 10. 0. R2

1/ 2 : Ti MOS-M- 10. 0. R13/ 2 : Ti MOS-M- 10. 0. R1

==============================================================================

A: Cpm- A# show mda

==============================================================================MDA Summar y


Mda- t ype Mda- t ype State Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1 2 i sa- aa i sa- ms up I SSU/ st andby

. . .

3 2 i sa- aa i sa- ms up I SSU/ acti ve

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 cardstate” output displays the time until the system resets the MS-ISA in the ISSU state.





==============================================================================

2. After the standby MS-ISA is reset and comes back up:

A: ALU- ABC>show>app- assure# ver si on==============================================================================

Vers i ons of i sa- aa. t i m i n use==============================================================================

CPM : Ti MOS- M- 10. 0. R2

1/ 2 : Ti MOS- M- 10. 0. R23/ 2 : Ti MOS- M- 10. 0. R1

==============================================================================

A: Cpm- A# show mda==============================================================================

MDA Summar y


Mda- t ype Mda- t ype State State

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1 2 i sa- aa i sa- ms up up/ st andby

. . .

3 2 i sa- aa i sa- ms up I SSU/ act i ve==============================================================================

3. After the MS-ISA activity switch (shutdown of active card to force activity switch):


Vers i ons of i sa- aa. t i m i n use

==============================================================================CPM : Ti MOS- M- 10. 0. R2

1/ 2 : Ti MOS- M- 10. 0. R2

3/ 2 : Ti MOS- M- 10. 0. R1==============================================================================

A: Cpm- A# show mda

==============================================================================MDA Summar y

==============================================================================

Sl ot MDA Provi si oned Equi pped Admi n Oper at i onal Mda- t ype Mda- t ype State State

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 2 i sa- aa i sa- ms up up/ acti ve

. . .3 2 i sa- aa i sa- ms down I SSU/ st andby

==============================================================================

4. After the newly inactive MS-ISA is reset, comes back up (clear command executed) and isre-enabled (“no shutdown” executed):


Vers i ons of i sa- aa. t i m i n use

==============================================================================CPM : Ti MOS- M- 10. 0. R2

1/ 2 : Ti MOS- M- 10. 0. R2





3/ 2 : Ti MOS-M- 10. 0. R2==============================================================================

A: Cpm- A# show mda==============================================================================

MDA Summar y==============================================================================

Sl ot MDA Provi si oned Equi pped Admi n Oper at i onal Mda- t ype Mda- t ype State Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 2 i sa- aa i sa- ms up up/ acti ve. . .

3 2 i sa- aa i sa- ms up up/ st andby

==============================================================================

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 applicationsand 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 ProcedureThis 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.





ISSU limitations listed under Known Limitations on page 183 should be taken into account for

planning purposes before the ISSU is performed.

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

New software loads may make modifications to the configuration file which are not compatiblewith older versions of the software.

Alcatel-Lucent recommends performing an “admin save” and then making backup copies of the

BOOT Loader (boot . l dr ), 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.

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 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 correctPhase B for your upgrade scenario.

Note:









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 . l dr 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 . l dr . 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 . cf g) is read by the BOOT Loader and indicates primary,

secondary and tertiary locations for the image file.• The bof . cf g should be modified as appropriate to point to the image file for the release

to be loaded.

• Use the “bof save” command to save the Boot Options File modifications.

STEP 5 Synchronize Boot Environment

Once the Boot Options File has been modified, the active and standby CPM or CFM boot

environments must be synchronized.

• Use “admi n r edundancy synchr oni ze 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: r out er1# show car d

==============================================================================

Car d Summar y==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper at i onal Card- t ype Card- t ype St ate Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2 i om- 20g- b i om- 20g- b up up


4 i om- 20g- b i om- 20g- b up up5 i om- 20g- b i om- 20g- b up up

A sf m- 200g sf m- 200g up up/ act i ve

B sf m- 200g sf m2- 200g up up/ st andby





==============================================================================

The cards will look like the following for systems with CFMs:

A: r out er1# show card

==============================================================================Car d Summar y

==============================================================================Sl ot Provi si oned Equi pped Admi n Oper ati onal

Card- t ype Card- t ype St ate St ate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1 i om- xp i om- xp up up

A cf m- xp cf m- xp up up/ act i ve

B cf m- xp cf m- xp up up/ st andby

==============================================================================

• Use “admi n reboot st andby now” to reboot the standby CPM/CFM and start the

ISSU process.

The cards for systems with CPMs will look like the following:A: r out er1# admi n reboot st andby now


==============================================================================

Car d Summar y==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper at i onal

Card- t ype Card- t ype Stat e St ate- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -





B sf m- 200g up down/ st andby==============================================================================

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.


==============================================================================

Car d Summar y==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper at i onalCard- t ype Card- t ype St ate Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -





B sf m- 200g sf m2- 200g up synchi ng/ st andby





==============================================================================

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.


==============================================================================

Car d Summar y==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper ati onal

Card- t ype Card- t ype St ate Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2 i om- 20g- b i om- 20g- b up up




B sf m- 200g sf m2- 200g up I SSU/ st andby==============================================================================

For systems with CFMs:


==============================================================================Car d Summar y

==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper ati onalCard- t ype Card- t ype St ate Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 i om- xp i om- xp up upA cf m- xp cf m- xp up up/ act i veB cf m- xp cf m- xp up I SSU/ st andby

==============================================================================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.

http://-/?-

http://-/?-

http://-/?-





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: r out er1# admi n r edundancy f orce- swi t chover Ti MOS- C-5. 0. Rx cpmbot h/ hops ALCATEL SR 7710 SR 7750 ESS 7450 Copyr i ght ( c)

2000- 2007 Al catel - Lucent.

Al l r i ght s r eser ved. Al l use subj ect t o appl i cabl e l i cense agr eement s.Bui l t on ddd mmm d hh: mm: ss PST 2007 by bui l der i n / r el 5. 0/ panos/ mai n

<. . . >

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 re-

established on the newly active CPM/CFM.

STEP 10 (Minor ISSU) Wait for Standby CPM/CFM to Synchronize

Before continuing with the ISSU procedure, the standby CPM/CFM must re-synchronize by

transitioning from “down”, to “synchronizing”, and finally to the “up” state. Use the 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: r out er1# show card

==============================================================================Car d Summar y

==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper at i onalCard- t ype Card- t ype St ate Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2 i om- 20g- b i om- 20g- b up I SSU3 i om- 20g- b i om- 20g- b up I SSU

4 i om- 20g- b i om- 20g- b up I SSU

5 i om- 20g- b i om- 20g- b up I SSUA sf m- 200g up down/ st andby

B sf m- 200g sf m2- 200g up up/ act i ve

==============================================================================


==============================================================================

Car d Summar y

==============================================================================Sl ot Provi si oned Equi pped Admi n Oper at i onal






- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2 i om- 20g- b i om- 20g- b up I SSU



A sf m- 200g sf m- 200g up synchi ng/ st andbyB sf m- 200g sf m2- 200g up up/ act i ve

==============================================================================

B: r out er1# show car d

==============================================================================

Car d Summar y

==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper ati onalCard- t ype Card- t ype St ate Stat e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



5 i om- 20g- b i om- 20g- b up I SSUA sf m- 200g sf m- 200g up up/ st andby


==============================================================================

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.





The sample output below shows the operational state transition for a single IOM/IMM.

B: Sof t Reset 1# cl ear car d 4 sof t

B: Sof t Reset 1# show card

==============================================================================

Car d Summar y==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper at i onal


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2 i om- 20g- b i om- 20g- b up I SSU


4 i om- 20g-b up sof t r eset5 i om- 20g- b i om- 20g- b up I SSU

A sf m- 400g sf m2- 400g up up/ st andbyB sf m- 400g sf m- 400g up up/ act i ve

========================================================================

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.


==============================================================================

Car d Summar y

==============================================================================Sl ot Provi si oned Equi pped Admi n Oper at i onal


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2 i om- 20g- b i om- 20g- b up I SSU3 i om- 20g- b i om- 20g- b up I SSU


5 i om- 20g- b i om- 20g- b up I SSUA sf m- 400g sf m2- 400g up up/ st andby

B sf m- 400g sf m- 400g up up/ act i ve

==============================================================================

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 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: rout er1# cl ear card 2


==============================================================================

Car d Summar y

==============================================================================Sl ot Provi si oned Equi pped Admi n Oper ati onal


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2 i om- 20g- b up pr ovi si oned


4 i om- 20g- b i om- 20g- b up up5 i om- 20g- b i om- 20g- b up I SSUA sf m- 200g sf m- 200g up up/ st andby


==============================================================================

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.


==============================================================================Car d Summar y

==============================================================================

Sl ot Provi si oned Equi pped Admi n Oper ati onalCard- t ype Card- t ype St ate Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


3 i om- 20g- b i om- 20g- b up I SSU4 i om- 20g- b i om- 20g- b up up


A sf m- 200g sf m- 200g up up/ st andbyB sf m- 200g sf m2- 200g up up/ act i ve

==============================================================================

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





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 MAJ OR: CHASSI S #2001 Base Car d B"Cl ass CPM Modul e : f ai l ed, r eason: I ssu Unsupport ed Scenari o, No Rel oad"

121 2012/ 05/ 30 16: 21: 03. 84 EDT MAJ OR: CHASSI S #2001 Base Car d B"Cl ass CPM Modul e : f ai l ed, r eason: Unsupport ed MDA t ype m4- choc3- sf p i n

sl ot 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:

WARNI NG: Af t er swi t chover t he f ol l owi ng HARD and SOFT reset s wi l l 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

==============================================================================Car d Summar y

==============================================================================

Sl ot Pr ovi si oned Equi pped Admi n Oper at i onal Comment s

Card- t ype Card- t ype Stat e Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 i mm1- 100gb- cf p i mm1- 100gb- cf p up up

2 i mm12- 10gb- sf + i mm12- 10gb- sf + up up3 i mm5- 10gb- xf p i mm5- 10gb- xf p up up

4 i om3- xp- b up unprovi si oned

5 i om2- 20g i om2- 20g up up7 i mm3- 40gb- qsf p i mm3- 40gb- qsf p up up

8 i om2- 20g i om2- 20g up up

9 i om2- 20g i om2- 20g up up

10 i om3- xp i om3- xp up upA s f m3- 12 sf m3-12 up up/ act i ve

B sf m3- 12 sf m3- 12 up I SSU/ st andby

http://-/?-

http://-/?-

http://-/?-





==============================================================================

A: Dut - A# show mda

==============================================================================MDA Summar y

==============================================================================Sl ot Mda Provi si oned Equi pped Admi n Oper at i onal

Mda- t ype Mda- t ype Stat e Stat e- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 1 i mm1- 100gb- xp- cf p i mm1- 100gb- xp- cf p up up

2 1 i mm12- 10gb- xp-sf + i mm12- 10gb- xp-sf + up up3 1 i mm5- 10gb-xp- xf p i mm5- 10gb- xp- xf p up up

5 1 m20- 1gb- xp- sf p m20- 1gb- xp- sf p up up

2 m4-choc3- as- sf p m4- choc3- as- sf p up up

7 1 i mm3- 40gb-xp- qsf p i mm3- 40gb- xp- qsf p up up8 1 m2- 10gb-xp- xf p m2- 10gb- xp- xf p up up

2 m1- 10gb- dwdm- t un m1- 10gb- dwdm- t un up up

9 2 m4-choc3- as- sf p m4- choc3- as- sf p up up10 1 m10- 1gb- xp- sf p m10- 1gb- xp- sf p up up

2 m10- 1gb- hs- sf p- b m10- 1gb- hs- sf p- b up up

==============================================================================

A: Dut- A# admi n r edundancy f orce- swi t chover

WARNI NG: Af t er swi t chover t he f ol l owi ng HARD and SOFT r eset s wi l l occur :I OM 1: SOFT ( MDAs: 1/ 1 SOFT)

I OM 2: SOFT ( MDAs: 2/ 1 SOFT)

I OM 3: SOFT ( MDAs: 3/ 1 SOFT)I OM 4: HARD ( of f l i ne)

I OM 5: SOFT ( MDAs: 5/ 1 SOFT, 5/ 2 HARD ( unsuppor t ed) )

I OM 7: HARD ( no Sof t Reset capabl e MDAs: 7/ 1 i ncompat i bl e)I OM 8: SOFT (MDAs: 8/ 1 SOFT, 8/ 2 SOFT)

I OM 9: HARD ( no Sof t Reset capabl e MDAs: 9/ 1 not present , 9/ 2 unsuppor t ed)

I OM 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:

WARNI NG: Maj or i n servi ce sof t ware upgr ade i n pr ogr ess.Ar e you sur e you want t o swi t chover ( 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:

MI NOR: CHMGR #1055 - Maj or I SSU sync of conf i g t o st andby f ai l ed





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 SessionIf 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, theywill be given the following error:

*B: Dut- A# conf i gure servi ce epi pe 3 cust omer 1 cr eat eMI NOR: CLI Command not al l owed whi l e becomi ng act i ve.

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:

Ti MOS- C-11. 0. B1- 106 cpm/ hops ALCATEL SR 7750 Copyr i ght ( c) 2000- 2012 Al cat el -Lucent .

Al l r i ght s r eser ved. Al l use subj ect t o appl i cabl e l i cense agr eement s.

Bui l t on Mon May 28 18: 44: 43 PDT 2012 by bui l der i n / r el 11. 0/ b1/ B1-

106/ panos/ mai nKANHWSYNC1 - Dut - A

Logi n: admi n

Passwor d:

*B: Dut- A# show r edundancy synchroni zat i on==============================================================================Synchr oni zati on I nf ormati on

==============================================================================

St andby St atus : di sabl edLast St andby Fai l ur e : N/ A

St andby Up Ti me : N/ A

Standby Vers i on : N/ A

Fai l over Ti me : 05/ 30/ 2012 16: 00: 33





Fai l over Reason : user f orced swi t choverBoot / Conf i g Sync Mode : None

Boot / Conf i g Sync St atus : No synchr oni zati on

Last Conf i g Fi l e Sync Ti me : NeverLast Boot Env Sync Ti me : Never

Rol l back Sync Mode : NoneRol l back Sync St atus : No Rol l back synchr oni zati on

Last Rol l back Sync Ti me : Never==============================================================================

*B: Dut- A# show card==============================================================================

Car d Summar y

==============================================================================

Sl ot Provi si oned Type Admi n Oper at i onal Comment s Equi pped Type ( i f di f f er ent ) St at e St at e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 i mm1-100gb- cf p up sof t r eset ( not equi pped)

2 i mm12- 10gb- sf + up sof t r eset

( not equi pped)3 i mm5-10gb- xf p up sof t r eset

( not equi pped)

5 i om2-20g up sof t r eset ( not equi pped)

7 i mm3-40gb- qsf p up provi si oned

( not equi pped)8 i om2-20g up sof t r eset

( not equi pped)

9 i om2-20g up provi si oned ( not equi pped)

10 i om3-xp up sof t r eset

( not equi pped)A sf m3- 12 up down/ st andby

( not equi pped)

B sf m3-12 up up/ act i ve==============================================================================

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.

==============================================================================Car d Summar y

==============================================================================

Sl ot Provi si oned Type Admi n Oper at i onal Comment s Equi pped Type ( i f di f f er ent ) St at e St at e

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 i mm1-100gb- cf p up sof t r eset2 i mm12- 10gb- sf + up sof t r eset

3 i mm5-10gb- xf p up sof t r eset

4 ( not provi si oned) up unpr ovi si oned i om3- xp- b

5 i om2-20g up sof t r eset

7 i mm3- 40gb-qsf p up boot i ng8 i om2-20g up sof t r eset

9 i om2- 20g up boot i ng

10 i om3-xp up sof t r esetA sf m3- 12 up down/ st andby

B sf m3-12 up up/ act i ve





==============================================================================

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.

==============================================================================

Car d Summar y==============================================================================

=

Sl ot Provi si oned Type Admi n Oper at i onal Comment s

Equi pped Type ( i f di f f er ent ) St at e St ate- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 i mm1- 100gb- cf p up up

2 i mm12- 10gb-sf + up up3 i mm5- 10gb- xf p up up

4 ( not pr ovi si oned) up unprovi si oned

i om3- xp- b5 i om2- 20g up up

7 i mm3- 40gb- qsf p up up8 i om2- 20g up up

9 i om2- 20g up up10 i om3- xp up up

A sf m3- 12 up synchi ng/ st andby

B sf m3- 12 up up/ act i ve==============================================================================

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”).

==============================================================================

Car d Summar y

==============================================================================Sl ot Provi si oned Type Admi n Oper at i onal Comment s

Equi pped Type ( i f di f f er ent ) St at e St ate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1 i mm1- 100gb- cf p up up

2 i mm12- 10gb-sf + up up

3 i mm5- 10gb- xf p up up4 ( not pr ovi si oned) up unprovi si oned

i om3- xp- b

5 i om2- 20g up up

7 i mm3- 40gb- qsf p up up8 i om2- 20g up up

9 i om2- 20g up up

10 i om3- xp up upA sf m3- 12 up up/ st andby

B sf m3- 12 up up/ act i ve

==============================================================================





*B: Dut- A# show r edundancy synchr oni zat i on

==============================================================================Synchr oni zati on I nf ormati on

==============================================================================Standby Stat us : st andby r eady

Last Standby Fai l ur e : N/ ASt andby Up Ti me : 2012/ 05/ 30 16: 05: 03

St andby Ver si on : Ti MOS- C- 11. 0. B1- 106 cpm/ hops ALCATEL SR 7750

Copyri ght ( c) 2000- 2012 Al catel - Lucent . Al l r i ght s reser ved. Al l use subj ect t o

appl i cabl e l i cense agr eement s.

Bui l t on Mon May 28 18: 44: 43 PDT 2012 by

bui l der i n / r el 11. 0/ b1/ B1- 106/ panos/ mai nFai l over Ti me : 05/ 30/ 2012 16: 00: 33

Fai l over Reason : user f orced swi t chover

Boot / Conf i g Sync Mode : NoneBoot / Conf i g Sync St atus : No synchr oni zati on

Last Conf i g Fi l e Sync Ti me : Never

Last Boot Env Sync Ti me : NeverRol l back Sync Mode : None

Rol l back Sync St atus : No Rol l back synchr oni zati on

Last Rol l back Sync Ti me : 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 acard 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 . l dr ). The BOOT Loader performs two

functions:

1. Initiates the loading of the SR OS image based on the Boot Options File (bof . cf g) set-

tings





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 pro-

gramming is required.

STEP 1 Back up Existing Images and Configuration Files

New software loads may make modifications to the configuration file which are not compatible

with older versions of the software.

Alcatel-Lucent recommends performing an “admin save” and then making backup copies of the

BOOT Loader (boot . l dr ), 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.

Note:

An “admin reboot upgrade” is required for all 7450 ESS-6/6v chassis running Release 6.1.R2

or earlier.

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 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.

Note:









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 . l dr 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 . l dr . 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 . cf g) is read by the BOOT Loader and indicates primary,

secondary and tertiary locations for the image file. The bof . cf g 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 “admi n r edundancy synchr oni ze 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 Ver ify the Software Upgrade

Allow the boot sequence to complete and verify that all cards come online.

Note:

If isa-aa.tim file was present in the image path the last time the node booted and an “adminsave detail” was performed, the configuration will fail to load completely if the isa-aa.tim file

is missing in the new image path.



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.

It is recommended to save the configuration “admin save” after an upgrade has been performedand 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:

- 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

EPIPE/VPLS • 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

Note:

If any card fails to come online after the upgrade, contact the Alcatel-Lucent Technical

Assistance Center for information on corrective actions.



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 QinQPWs

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>, <delete-

config>, <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.

Soft Reset • Although the data plane interruption during a Soft Reset is minimized, there is a brief (non-

zero) traffic interruption. Transit protocol packets can be affected by this interruption.

• In scaled configurations, the following protocols may experience interruptions in peering

sessions during a Soft Reset on the 7950 XRS line cards when using the default protocol

timers:

- Broadcast IS-IS (point-to-point IS-IS is not impacted)

- RSVP

- P2MP LSPs

- LDP (T-LDP is not impacted).

Increasing the protocol timers in the configuration will prevent interruptions in the protocol

peering sessions. BFD (which is not impacted by the Soft Reset traffic interruption) could

be used in conjunction with larger protocol timers in order to have fast failure detection.

• If the far-end node of an Ethernet OAM (802.3ah) session is not an SR OS router with the

support for the vendor-specific Grace TLV, then the Ethernet OAM sessions are interrupted

briefly during a Soft Reset and will take down the associated port and protocols running on

that port. Ethernet OAM grace is disabled at the system level by default and must beenabled 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.

• 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 thegrace-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-unsupported-

mdas functionality for a manual clear/reset during a Minor ISSU. In most software upgrade

cases, these cards can simply be Soft Reset (without the need for the hard-reset-

unsupported-mdas), but if there is a mandatory firmware update on these cards, then they

must be hard reset. The hard-reset-unsupported-mdas option is blocked for the following

IMM types: imm1-40gb-tun, imm5-10gb-xfp, imm1-100gb-cfp, imm12-10gb-sf+, imm3-

40gb-qsfp, imm-1pac-fp3 and imm-2pac-fp3. [158482]

ISSU • ISSU can use the Soft Reset mechanism and if used, is subject to any limitations of Soft

Reset in the source/starting release of the upgrade. 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 port-

based 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 cardsduring 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/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 [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]



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.R x -> 11.0.R y where:

- x and y are >= 4

- The release date of 11.0.R y 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]

• An ‘admin reboot upgrade’ is required during the upgrade process to SR OS Release9.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


FlowSpec • For flow routes, there is no support for next-hop resolution, interaction of router policies

and flow route NLRI fields, or configurable prefix-limit.

• Installed validated flowroutes do not disappear when next-hop disappears.

• Packets with options hit the filter entry, but are still forwarded to the CPM/CFM and routed

via routing table information.

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.

• On the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-atmoc12/3-sfp, and

m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA, only the first 16 bytes of the 62 byte

trace string can be unique for each group of four (4) ports (for example, for ports 1 through

4 or 13 through 16) for ports operating in SONET mode at OC-3. The last 48 bytes of the

trace string will be the same for all ports and will be the last value set. Basically, a unique

trace string per port is not possible if the unique part of the string is longer than 14

characters.

• On the m16-oc12/3-sfp, m8-oc12/3-sfp, m16-oc3-sfp, m8-oc3-sfp, m4-atmoc12/3-sfp, and

m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA, the normal range for the

SONET/SDH line signal failure Bit Error Rate (BER) threshold configured using the

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, m4-

atmoc12/3-sfp, and m16-atmoc3-sfp MDAs and the c2-oc12/3-sfp CMA are serviced in

groups of four (1-4, 5-8, 9-12, 13-16) by a single framer chip, and as such, all must have

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



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:

- 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]

APS • Ports that are part of an MLFR bundle or that contain an MFLR bundle cannot be APS

protected.

• APS is not supported on MDAs/CMAs that support LAN and WAN-PHY mode for 10G

ports (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:- Bundles are not supported on ports (or contain ports) that are protected with uni-

directional SC-APS.

- Uni-1plus1 SC-APS is supported only on the 7750 SR-c4/c12 platforms. Only the

following cases are supported:

- POS ports on non-channelized MDAs configured in network mode

- CES ports configured in access mode where only Cpipe services (SAPs) are

configured on that port.

- ASAP channelized ports with MLPPP where the ports are configured in network

mode.

• Restrictions specific to MC-APS:

- Network mode ports cannot be part of an MC-APS group.- Ipipe SAP cannot be on a port that is part of an MC-APS group.

- Routing protocols cannot be run over MC-APS protected ports (however, static

routing is allowed).

- BFD and VRRP over MC-APS protected ports are not supported.

- The only type of bundle that can be bi-directional MC-APS protected is MLPPP with

IPCP encapsulation (on ports configured in access mode).



Known Limitations


- 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]

ASAP MDA

Limitations

• 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.

ATM MDAs

Access Mode Only

• The ATM interfaces on non-ASAP MDAs in the table below only support the customer-

facing access mode.

For more information on the ASAP MDA, see ASAP MDA Limitations on page 189.

ATM and IS-IS • IS-IS is not supported on IES and VPRN interfaces with ATM PVC SAPs in this software

release.

ATM Traff ic

Management

Limitations

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 fairnessVC 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.)




3HE05944AA 16-port ATM OC-3c/STM-1c MDA - SFP Rev B

3HE05945AA 4-port ATM OC-12c/STM-4c MDA - SFP Rev B



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

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.

Class of Service

Fairness Affected

on Shaped VCs

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 linkwill 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).



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 willautomatically 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 odd-

even slot pairs (for example, slots 1&2, 3&4, 5&6, 7&8, 9&10 and 11&12). However, it is

possible to have a 5-port GigE CMA in slot 2 beside a 1-port GigE in slot 3.

• Ethernet hold-timer on an m1-10gb-dwdm-tun MDA will be off by 300 ms to one (1)

second because it may take longer for the port to come up. [91562]

• Due to event suppression of Ethernet port states, a port that bounces while transitioning up

or down may not take on its steady state for at least a second. Any port hold-timer

configuration of less than one (1) second will effectively look like a one (1) second hold-

timer. [91563]

• 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



Known Limitations


number of multicast capable paths is different between these card types; these

configurations must not be used. [118443]

• 7750 SR-7 SF/CPM4 (3HE05949AA) is not supported in the 7750 SR-12 chassis.

Similarly, 7450 ESS-7 SF/CPM4 (3HE05951AA) is not supported in the 7450 ESS-12

chassis.

• 7750 SR-12 SF/CPM4 (3HE05948AA) is not supported in the 7750 SR-7 chassis.

Similarly, 7450 ESS-12 SF/CPM4 (3HE05950AA) is not supported in the 7450 ESS-7

chassis.

• 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 thechannel, 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.

RADIUS • If the system IP address is not configured, RADIUS user authentication will not be

attempted for in-band RADIUS servers unless a source-address entry for RADIUS exists.

• The NAS-IP-Address selected is that of the management interface for out-of-band

RADIUS servers. For in-band RADIUS servers if a source-address entry is configured, the

source-address IP address is used as the NAS-IP-Address, otherwise the IP address of the

system interface is used.

• SNMP access cannot be authorized for users by the RADIUS server. RADIUS can be used

to authorize access to a user by FTP, console or both.

• If the first server in the list cannot find a user, the server will reject the authenticationattempt. 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


• 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.

Accounting • The extended-service-ingress-egress record accounting is designed only for lower-scale

deployments that require extra information and is not available in other types of records.

• When extended-service-ingress-egress record is selected for an accounting policy, the

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]

TACACS+ • If the TACACS+ start-stop option is enabled for accounting, every command will result in

two commands in the accounting log.

• If TACACS+ is first in the authentication order and a TACACS+ server is reachable, the

user will be authenticated for access. If the user is authenticated, the user can access the

console and any rights assigned to the default TACACS+ authenticated user template(“config>system>security>user-template tacplus_default”). Unlike RADIUS, TACACS+

does not have fine granularity for authorization to 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 reach-

able, authorization for console access for the user is checked against the user’s local or

RADIUS profile if configured. If the user is not authorized in the local/RADIUS profile,

the user is not allowed to access the 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 becauseTACACS+ does NOT provide granularity in terms of granting FTP or console access. If the

TACACS+ server is DOWN, the user will be denied access to the console as the local pro-

file only authorizes FTP access. [39392]

CLI • The CLI allows the user to specify a TFTP location for the destination for the “admin save”

and “admin debug-save” commands which will overwrite any existing file of the specified

name. [18554]

• 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



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]

• 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 aCPM/CFM failover occurs (the candidate will be empty).

System • 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 higher-

based line cards, egress discards are always increased, even when a “do-not-

fragment” message is not sent. On iom2-20g, egress discards are never increased,

even when a “do-not-fragment” message is sent. [193662]

IPsec • In a multi-active tunnel group setup, ICMP pings to the tunnel’s 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]



Known Limitations


ATM • ATM ports whose operational state toggle at a high rate (faster than both the up and down

hold timers) may remain in a “Link Up” but not be in the operationally-up state. The

workaround is to wait for the hold timer to expire before issuing the “no shutdown”

command. [35066]

• ATM port statistics for AAL5 packets include all AAL type frames as well as ATM cellsreceived 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]

VSM-CCA • 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]

ASAP • In exceptional cases, especially in a fully loaded node, where the occurrence of a High-

Availability CPM or CFM switchover is exactly concurrent with an APS switch from

Working to Protect (both unidirectional or bi-directional failures), PSBF may potentially be

posted by the Far-End node during the APS K1/K2 byte exchange due to the increase

latency response of the Near-End where the CPM or CFM switchover is occurring. [41192]



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 tothe available paths. If on the intermediate system (B), the flows ingress on both an IOM3-

XP/IMM and an IOM-20g-b or IOM2-20g, different algorithms will be used to determine

the egress paths to the next system (C) and may result in some egress paths having more

flows than the others. [72557]

• 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 round-

robin over the active links of the LAG irrespective of which link is used on egress by the

given SAP/network interface.

• On a LAG, CPM-originated, sub-second CFM/BFD packets use hashing independent ofthat 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-map-

profiles 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]



Known Limitations


• 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).

MLPPP • If several PPP member links in a MLPPP bundle are removed or shut down at the channel-

group level simultaneously, term-requests may not be sent out. In this event, the far-end

links may not be notified and the links may not become non-operational until PPP keep-

alives fail. To work around this issue, shut down member links at the physical level first (if

possible), or remove links or shut down channel groups one at a time. [87044]

• IPv6 interfaces over MLPPP bundles are only supported on ASAP MDAs even though the

system allows that configuration on other MDA/CMA types. [143700]

Management • 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 IESinterface 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 32-

bit limit. [51129]

• The following considerations apply to the IF-MIB enhancements introduced in Release

11.0.R5:

- 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 beupdated 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]

• 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]

Routing • Setting a metric of zero in OSPF or IS-IS is not supported and causes the interface to fall

back to the “reference-bandwidth” computed value instead of setting the value to zero.

[17488]• Routes exported from one protocol to another are redistributed with only the first ECMP

next-hop. Therefore, if BGP routes having multiple next-hops are exported to a VPRN

client, only one next-hop for the route will be exported. The one chosen is the lowest IP

address of the next-hop address list. [40147]

• 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 route’s next-hop information.



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]

DHCP • If the addition of the Option 82 information to a DHCP packet would cause the maximum

size of 1500 bytes to be exceeded, the DHCP relay 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]

RIP • The RIP global statistics for all RIP instances is incorrectly being displayed for each VPRN

instance. This has the effect of causing one to think that the VPRN instance has learned

routes when in fact it has not. [26472]

• When 16 bytes of authentication-key was configured in RIP, the last byte was filled with

the null character in Release 10.0 and Release 11.0 prior to 11.0.R6. Interoperability issues

would arise when the network consisted of SR OS routers running these older releases andthose running 11.0.R6 or higher. [167905]

TCP

Authent ication

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]



Known Limitations


• 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 time-

range-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]

IPv6 • 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 IPv6header 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

L2TPv3 SDP • The implementation of L2TPv3 for SDP transport does not support:

- Any L2TPv3 control plane functionality

- Support sequence numbering

- Fragmentation and reassembly

- Session ID configuration or validation

- Authentication – the only authentication of tunnel payload is performed through

validation of Source Address, Destination Address, and the ingress cookie

- Service multiplexing – each SDP will transport one spoke-SDP

Unless explicitly mentioned above, most pseudowire/Epipe features are not supported on

L2TPv3 SDPs or spoke-SDP bindings, including but not limited to:

- Layer-3 functionality <etc>

- Pseudowire shaping

- Ingress/egress QoS functionality- Pseudowire switching

- Active/standby pseudowire services and inter-chassis backup

- PBB

- Application Assurance

- Hash-label



Known Limitations


- PW Status signaling

Operators expecting to deploy this feature set should contact their Alcatel-Lucent engineer-

ing 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 com-

puted LFA can result in transient forwarding loops, based on the updated topology. This

could be especially amplified if the SPF timers are different, or if the routers in the network

are heterogeneous (different vendors, different route processor speeds/capability).

Note that the same sequence of convergence events can occur, even if ECMP > 1 is config-

ured, as long as there are more than MaxECMP paths available; the next-hop count of one

(1) is a special case of the same. [130305]

• When the LFA next-hop for a far-end GRE tunnel is activated, packets of a spoke-interfacedo 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]

OSPF • The system may refresh self-originated LSA shortly after completing a CPM or CFM

switchover which may mean the entry is refreshed before the expiration of the age-out

period. [65195]

• 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 itdetects 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]



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, somekind 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 dis-

abled. [60261]

• If a local IP address is configured with the same address as the destination address of an

MPLS LSP, the LSP will no longer be set up and will use the RSVP error code of

“routingError”. [73326]



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 isdifferent from system interface. Inter-area manual bypass association does work correctly

for the following supported RESV RRO formats for the primary LSP path: SLIL, ILSL,

SIL, SLI, ISL and SL.

S: RRO object with system ID

I: RRO object with interface ID

L: RRO label object

If no node supports any of the formats above, the bypass LSP association to protect LSP

may be incorrect. [109753]

• A manual bypass LSP may not come up if the user specifies a local interface address of a

node in the “exclude-node” configuration of that LSP. When computing the CSPF path at

the ingress (LER) or transit LSR (ABR), if the local interface is down or not part of the IGP

or not in the same area as the node doing the CSPF computation, MPLS will be unable toresolve 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 PATHmessage of an LSP did not include the RRO.

LDP • If triggered-policy is configured, LDP policies are not dynamically evaluated for changes

in FECs. [71830]

• It is not possible to apply an accounting policy in the egress LDP statistics context if both

"default" and "combined-ldp-lsp-egress" are configured in that policy. [84406]



Known Limitations


• 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 whenthe 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 sucha time the LDP session bounces. [163266]

IP Multicast • 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 re-

enabled. The used bandwidth remains at zero for the static groups. In addition, the MCAC

recalculation command “tools perform service id id mcac sap sap recalc policy policy” fails

to recalculate the used bandwidth, and the use of the 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 properoperation, one of the following must be true:

- MCS is configured with a sync-tag for the entire port

- The IGMP snooping SAP and the MCS sync tag must be provisioned with the same

Q-tag values. [102473]

• When MoFRR for PIM is enabled, tunnel interfaces (for example, dynamic in-band mLDP

interfaces) are ignored for MoFRR functionality.



Known Limitations


• 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 asif 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 mutuallyexclusive with PIM LAG usage optimization (config>router>pim>lag-usage-

optimization), since CPM-based load-balancing cannot mimic data-path-based load-

balancing in general cases (source IP unknown). Enabling both options at the same time is

not blocked, but may lead to multicast traffic disruptions and thus, must be avoided.

[179614]

PIM • 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]

QoS • 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 behavioris 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



Known Limitations


which the line card will allocate multicast queues and the line card and CPM will be in

sync. [42469]

• 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 outthe egress port. This can also occur if the traffic is on two separate queues that are mapped

to the same level. [59298, 59435]

• Small amounts of packet loss may occur on queues configured with an MBS equal to or

lower than 4 KB and/or lower than two (2) times the maximum packet size of packets

forwarded by these queues. This can happen when the traffic rate through these queues is

large or when there is a large amount of jitter on this traffic. This packet loss is possible on

queues where the traffic rate is lower than the PIR. To avoid this type of packet loss, the

MBS of a queue should be configured to a minimum value of 5 KB or to two (2) times the

maximum expected packet size, whichever is higher. [66687]

• When sizing the mega pool based on the buffer-allocation requirements, the size is rounded

up to the nearest m5e4 and may result in no buffers being available for other pools. In non-

named-pool-mode, all port pools are guaranteed a minimum size of 16k (which is roundedup to 6 buffers=18k). This guarantee does not apply to named-pool-mode and named pools

still have no minimum size (could be zero), but MDA default pools now have a minimum

size of 1 Mbyte. [80716]

• When the agg-rate-limit option is enabled on a vport used by a subscriber, any subscriber

host queue that is parented to a virtual scheduler is not rate-limited by the vport aggregate

rate. The queue will compete for bandwidth directly on the port's port scheduler, at the

priority level and weighted scheduler group at which the virtual scheduler is port-parented.

If the virtual scheduler is not port-parented, or if there is no port scheduler policy on the

port, the host queue will be orphaned and will compete for bandwidth directly based on its

own PIR and CIR parameters. [109318]

• WRR distribution across CVLANs will not be correct for certain combinations of class-

agg-weight and frame size, such that frame_size/class-agg-weight results in a value lowerthan 64 bytes. Hardware will round up the value resulting from frame_size/class-agg-

weight 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 offered-

combined by a multi-point service queue is accounted as offered-uncolored in the

forwarding engine statistics on FP3-based line cards. [128123]• Out-of-profile unicast traffic that is accounted as offered-colored by a unicast service queue

is accounted as offered-hi-priority in the forwarding engine statistics on FP3-based line

cards. [128133]

• When applying an ingress network-queue policy on an MDA that belongs to an IOM with

only one complex (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]

• 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-qosmodes, 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]

PBR/TCS • If a Transparent Cache Switching (TCS) redirect-policy destination does not have a test

clause defined, the operational state is reported as “Up”. [21227]

• An IP address must be assigned to the system interface and the interface must be

operationally up in order for Web portal or HTTP-redirect to operate. [46305]

Services General • The CLI does not display an error when the user attempts to apply a filter log and a mirror-

source to a given SAP at the same time. A filter log and mirror-source cannot be applied

simultaneously to the same SAP. [22330]

• When the standby spoke-SDP of an endpoint becomes active due to a revert-time

expiration or a forced switchover, the Multi-Tenant-Unit (MTU) SAP may forward

duplicated packets (only of broadcast/multicast/unlearned unicast types) coming from the

redundant spoke-SDPs for a few milliseconds. For broadcast TV distribution and similarapplications 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 IPunicast 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



Known Limitations


workaround is to set the ARP cache timeout to a lower value on the Ethernet CE router.

[78805]

• A Multi-Site Scheduler (MSS) must either have a single (card-level) scheduler hierarchy

instantiated, or have a scheduler-hierarchy instantiated per member port for multi-member

logical ports such as LAG and APS, but not both. When an APS SAP is added to an MSS,a site_instance is created for each APS group member port, and a scheduler hierarchy is

instantiated per site instance. If a regular (physical port) SAP was also to be added to the

same MSS, then a card-level scheduler hierarchy would be created. The per site-instance

scheduler hierarchies and the card-level scheduler hierarchy within the MSS are

disconnected and therefore would not provide a meaningful H-QoS function. [81279]

• A 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 packetsexceeding 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.

Subscriber

Management

• 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/LI’d using the subscriber ID as the mirror/LI source

criteria, but a specific IPv6 host cannot be a source criteria (only the subscriber which will

include all IPv6 hosts associated with that subscriber ID).

• When a CoA request is sent for changing the subscriber-ID of a subscriber host in a dual-

stack PPPoE session, both the IPv4 and IPv6 hosts will have their information changed.

This may temporarily increase the subscriber count on the SAP, which should be reflected

in the multi-sub-sap limit. [90556]

• In a network where DHCP relay is dual-homed, a VPLS SAP with DHCP snooping

enabled will receive two identical DHCP reply messages from the DHCP server. When

RADIUS authentication is enabled on the VPLS SAP and the DHCP server did not echo

the Option 82 information, RADIUS authentication will be executed again for DHCP reply

messages. For dhcpACK messages, if the SR OS still has an outstanding RADIUS

transaction from the first dhcpACK when receiving the second dhcpACK, the latter one

will be dropped and a dhcpRelease message will be incorrectly generated towards the

DHCP server. When RADIUS authentication is successful for the first dhcpACK, the clientwill 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 whichIGMP 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, igmp-snooping and mld-snooping. [123469]

• When using host-lockout on managed SAP's using one VLAN for all PPP sessions, some

sessions can become locked-out during the initial setup in case of high setup rates [126348]

• The maximum number of hosts within the subscriber or the sla-profile instance that can be

affected by a single CoA is 32.



Known Limitations


• 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 relayon 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-lease-time”. [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 twicetheir 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.



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/2547 • VPRN service traffic with the DF (Do Not Fragment) flag set and requiring fragmentation

to be transported through an SDP tunnel is correctly discarded, but an ICMP Type 3 Code 4

(fragmentation needed and DF set) message is not issued. [18869]

• The 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.



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-hopsshould be configured first, before the auto-bind GRE command is applied. [167012]

VRRP/SRRP • The MAC address displayed for an SRRP gateway IP in the “show router arp” output on a

subscriber interface does not show the MAC address of the Virtual Router but is that of the

interface. Use the “show srrp” command to see the VR MAC address actually in use.

[57838]

• 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 betransmitted. 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 processingis not supported on these platforms, except on 7450 ESS-7 or 7450 ESS-12 platforms with

mixed-mode enabled. [162472]

Mirroring / Lawful

Intercept

• 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



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 mirror-

dest type of ip-only. No other mirror-dest types are supported for MLPPP subscribers at the

LNS.

• If q-tagged traffic is mirrored to a mirror-destination SAP and the SAP has an egress QoS

policy containing IP-based reclassification, the IP-based reclassification is ignored.

[132504]

• NAT-based Lawful 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]

Appl ication

Assurance

• 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).



Known Limitations


• 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 app-group 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 retailer’s network, but not on both.

• When creating new AA group partitions, unique partition ID values should be used across

all groups.

• When creating AA policers, unique policer names should be used across all groups.• If hosts for a single ESM subscriber are present in multiple service instances, simultaneous

traffic in the separate service instances with the identical IP 5-tuple may be mis-classified

by AA. [91809]

• If Cflowd export from AA exceeds the rate that the CPM/CFM can process, Cflowd

packets may be silently discarded. [91811]

• At a 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.

Video • 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” com-

mand has two entries in that case: one for (*,G) and one for (S,G). The FCC/RET counters

should step up on the (S,G) entry, not the (*,G). If the (*,G) FCC/RET counters incre-



Known Limitations


ments, the workaround is to use the command “clear router pim database” to get out of the

state. [82353]

• In normal operating conditions, the RTP-sequence numbers for a channel are increasing

monotonically. An equipment failure upstream of the video-interface (i.e., rewrapper-issue,

intentional reset of sequence numbers,etc.) may lead to a situation where this assumptionno 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]

PPPoE • HTTP redirect is not supported for L2TP sessions at the LAC. Attempting to use HTTP

redirect IP-filters in ESM SLA-profiles that would be applied to L2TP sessions will block

the HTTP traffic on those sessions. [81316]

• Hierarchical Policing (H-POL) is not supported on L2TP LNS sessions.

• L2TP tunnel over GRE spoke-SDPs on an interface in a VRF is not supported.

• When using IPv6 subscriber management, all ports carrying traffic for subscriber hosts

must be on IOM3-XP/IMM cards or higher, including ports for non-subscriber-

management interfaces within the same router and network interfaces. IPv6 traffic comingin 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]

BFD • When an SRRP instance uses its own BFD, L3 MC-ring cannot be enabled. BFD may be

enabled in subscriber SRRP or MC-ring, but not both. [73063]

• 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


• 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 twoendpoints 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]

NAT • Executing a traceroute from an inside NAT interface may result in an unexpected source IP

address in the response packet when the max session limit is exceeded. [91154]

• There are some limitations to the functionality of the Application Layer Gateways (ALGs)

in combination with NAT64 due to the way the ALG translations are done.

When translating inside-information into outside information, IPv6 addresses are translatedinto IPv4 addresses without any issues, but when an IPv4 addresses is received in the pay-

load of an incoming message, this address will not be translated because it is a random

ouside address and not a NAT address. In the NAT44 case, this is not an issue because the

inside host can connect to this address, but in the NAT64 case, the inside host cannot con-

nect to an IPv4 host.

This has an impact on the possible scenarios involving the ALGs:

- SIP — The connection information in a SIP message describes the IP addresses and

ports to be used to connect to the other party of the call. From the perspective of a

client behind a NAT64 gateway, his own IP address will be translated correctly, but

the IP address received from the other side may be an IPv4 address and will not be

translated into an IPv6 address. Thus, the NAT64-client will not be able to initiate a

connection to the other client. If only one client is behind a NAT64 gateway, SIP-callsare still possible. When client A (IPv4) can connect to client B (NAT64), client B can

use this connection to connect back to client A. If both clients are behind the NAT64

gateway (the same or different), both clients will receive each other’s IPv4 outside

addresses and no client will be able to start the connection.

- RTSP — Connection information in an RTSP message 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 source-

address-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]



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 IPaddress 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 NAT’d 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 switchoveroccurs. 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]

OAM • Timestamping the SAA versions of Loopback and Linktrace are only applied by the sender

node. The total time of delay for Loopback and Linktrace tests includes the packet

processing time of the receiver node, which may be very inaccurate depending on the CPU

load of the receiver node at the processing time. Accurate results can be gathered through

the use of Y.1731 two-way-delay, which includes native time stamping and the removal ofremote 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]



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 withthe 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 LDPFEC 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 lsp-

trace packet for the next TTL value. If the LSR hashing the packet for the next TTL value

chooses a different downstream path to forward the packet, the error is returned by that

downstream node.• In order to properly trace the single path of a FEC, the user must add the path-destination

option and enter a specific 127/8 address to be used in the IP destination address field of the

echo request packet and in the DSMAP TLV such that the control plane and the data plane

at the hashing LSR will use the same downstream interface. In addition, the user can

discover all ECMP paths via the use of the ldp-treetrace command and trace all paths of the

FEC. [150970]



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 I-

PMSI in VPLS context [154657].

• p2mp-lsp-trace is not supported with an RSVP P2MP LSP used as an I-PMSI in VPLS

context. [154659]

• 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 configurationfor PBB-Epipes using spoke-SDPs. [163737]

Resolved Issues

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 • 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]

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 thenetwork.



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 “action-

owner” 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 couldhave 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]

MC-LAG • 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]

Routing • 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]



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 toL1, 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]

DHCP • Enabling “lease-populate” with the “route-populate” keyword on regular IPv6 service

interfaces in a DHCPv6-relay context caused IA_PD/IA_NA leases to be double-counted

in the lease-population counter, 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 DHCP-

snooped packet failed. This issue has been resolved. [212822-MI]

• Receiving a DHCP discover message while WPP host is logged in will trigger re-authentication, 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]

OSPF • 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:- “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 exe-

cuted many times and consumed a substantial amount of memory. This issue has been




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 switch-

over. This was only a display issue and has been resolved in Release 11.0.R20. [212828-

MI]

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 “buffer-

allocation” configuration was done while the “wred-queue-control” was in a “no

shutdown” state. This issue has been resolved. [215517-MI]

Filter Policies • 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]

Subscriber

Management

• The DS-Lite subscriber’s host bits are verified against the configured DS-Lite prefix

length, mandating that the host bits in Lawful Intercept (LI) command are set to zero (0).

This will ensure that a single LI mirror is created for the DS-Lite subscriber, irrespective of

the number of B4 elements (IPv6 addresses) under it. However, in previous releases, when



Resolved Issues


LI for DS-Lite was provisioned via SNMPv3, the host-bits verification was not performed.

Consequently, if an LI with non-zero host bits was configured via SNMPv3 and then saved

in a file, any attempt to restore such LI from the file on the current release would fail due to

non-zero host bits. This issue has been resolved. [206105-MA]

• 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


VPLS • 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]

IPsec • 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 beenresolved. [212241-MI]

• 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]

Video • An accounting policy that collected video records to a file that was located on a non-existing or non-functional compact flash would have caused a continuous increase of

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 “nat-

group” three or more times could have resulted in system instability. This issue has beenresolved. [211156-MA]

Appl ication

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]






Resolved Issues


HW/Platform • 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 a7950 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]

CLI • 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]

System • In rare cases, an MS-ISA inserted in an IOM3-XP card might have reset or might have

dropped a very small number of packets over a long period of time. This 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 havesometimes 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 routerisis 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 “route-

nh-template” configured with “protection-type link” was added to an IS-IS interface, after



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 • OSPF may have incorrectly advertised a leaked route when two nodes were leaking thesame 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


BGP • A remote BGP-VPN route tunneled via RSVP could have its age updated incorrectly but

without service impact when the RSVP backup path changed. This issue has been resolved.

[187299-MI]

• In 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 issueand 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 configura-

tion. Refer to TA 15-0958 for more information. This issue has been resolved.

[212295-MA]

BGP-VPWS • In a single-homed BGP-VPWS scenario, re-evaluating a PW template using the command

“tools perform eval-pw-template policy-id allow-service-impact” after changes to its “sdp-include/exclude” statements would have succeeded, but the recreated BGP-VPWS PW

would have lost any operational group association, BFD status or endpoint association. If

the same re-evaluation was performed in a dual-homed BGP-VPWS scenario with two

signaled PWs, the command would have failed with the error message “the service cannot

support any more SDP bindings”. One of the PWs would have been recreated but would



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 haveincorrectly 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 appliedwould 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]



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

Aggregat ion

• 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 WLAN-

GW event “Could not initiate GTP uplink: OutOfResources” was generated due to memorydepletion, 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]

NAT • RADIUS accounting Request messages to a node acting as RADIUS proxy for large-scale

NAT (LSN) could have caused a memory leak in the “System” pool. After a longer period

of time, this could have resulted in a High-Availability switchover. This issue has been

resolved. [203293, 208709-MA]

• 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 subscriber-

aware 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]


• Under unexpected Microsoft Lync traffic conditions, the MS-ISA may have raised a traceevent 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




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 goneinto 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 FPsThe 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-pol-

icy), applying the preventive workaround required a subsequent change of bandwidth-pol-



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 forsome 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]




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 trap-

target” configuration. [201542-MI]

BGP • After a lot of network churn, or some other condition that triggered a high number of BGP-

AD auto-generated SDP delete and recreate events, it was possible for the ID used for anewly 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

Aggregat ion

• 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]

Appl ication

Assurance

• 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]






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 LSA’s 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]




HW/Platform • 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


System • 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 beenresolved. [189859-MI]

• 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]



Resolved Issues


BGP • 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 multi-

homed 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 source-

PE 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 wasonly 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]



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





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 theswitchover 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: sap-

id , 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 SRRPinstances, 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

Aggregat ion

• 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 subnetspecified in the command. This issue has been resolved. [193205-MI]



Resolved Issues





HW/Platform • 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 Resetin Release 10.0. [191100-MI]

DHCP • 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]

• When using a dual-homed DHCP server fail-over setup with prefixes configured as access-

driven 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 local-

dhcp-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 MC-

LAG 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 “default-route-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]



Resolved Issues


IPsec • 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 correctlystopped and cleared. [189771-MI]

WiFi Offload and

Aggregat ion

• It was possible to erroneously remove the range configuration below WLAN-GW vlan-tag-

ranges 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-vlan-

range)”. 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]

Appl ication

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]




HW/Platform • 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 linecard types: imm-1pac-fp3 and imm-2pac-fp3 on 7750 SR and 7450 ESS; xcm-20 and xcm-

16 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.

This issue has been resolved. [182949-MI]• XCMs no longer fail a Soft Reset when the XCM uptime is greater than 58 days. [185942-

MA]

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 • 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



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.


LDP • 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



Resolved Issues


Acct-Session-Id and IP-address were incorrectly used, where only a match on Acct-

Session-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 tech-

support 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]



Resolved Issues



No technical issues were resolved in Release 11.0.R11 of SR OS since Release 11.0.R10.




HW/Platform • 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 HS-MDAv2 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 IOM3-

XPs, IMMs, and XCMs to recover automatically from memory errors on the switch fabric

interface was not working correctly for all types of memory errors. 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 SR-

12e, OSPF will no longer go into overload for a short period of time after a CPM High-

Availability 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-dhcp-

server 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]



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 weremismatched, 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. [181563-

MI]

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 BGP-

VPLS/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 con-

figured parameters of the associated pw-template. Starting in Release 11.0.R10, the param-

eters 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 MACaddress 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



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 thenumber 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. [180001-

MA]

Video • In rare cases, a large number of consecutive updates to the Outgoing Interface List forseveral 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 High-

Availability switchover. This issue has been resolved. [179771-MI]

Appl ication

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]

OAM • 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]



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]

OSPF • 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]

BGP • 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]

LDP • 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,



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]

PIM • 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 scheduler-

override 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]

VPLS • 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




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

Aggregat ion

• 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]

Appl ication

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

Following are specific technical issues that have been resolved in Release 11.0.R8 of SR OSsince Release 11.0.R7.

HW/Platform • 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. [169285-

MI]

• 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. [172533-

MI]

• 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]

CLI • 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]



Resolved Issues


System • Using “file version check” on a corrupted cpm.tim file will no longer result in a High-

Availability switchover. [167833, 174509-MA]

IPsec • In the case of IKEv1 phase-1 Delete informational exchange, the system ignored the phase-1 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. [176233-

MI]

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 system-

wide 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 forDHCPv6 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 inter-

operating 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]

BGP • 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-fault-

tolerance command had no influence on this behavior. This issue has been resolved.

[173926-MA]

LAG • 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]



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. [169672-MI]

WiFi Offload and

Aggregat ion

• Invalid DHCP information could have been sent in the RADIUS Access-Request DHCP-

options 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]

PPPoE • 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]



Resolved Issues


NAT • 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. Thisissue has been resolved. [175818-MA]

• 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]


• If statistics collection was being performed on a specific traffic flow that was beingterminated, 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]

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]



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 HS-

MDAv2 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. [172475-

MI]

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-of- band 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]



Resolved Issues


IPsec • 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 nowuse 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]

QoS • 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




Resolved Issues


Services General • 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 spoke-

SDP 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

Aggregat ion

• 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


Resolved in 11.0.R6





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 XMAswere 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-of-

band 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 aHigh-Availability switchover. [167833-MA]

Filter Policies • 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]



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 re-

established 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 waschanged (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]

BGP • 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



Resolved Issues


established instead. A workaround was to toggle the peer (shutdown/no-shutdown). This


• 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]

LDP • 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 local-

lsr-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


• 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


QoS • 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]

Subscriber

Management

• 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 atreboot. 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 Framed-

Routes 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


• 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]

RIP • 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.



Resolved Issues



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. [166775-

MI]

• 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 “def-

sub-id”. This issue has been resolved. [167590-MI]

Appl ication

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. [164974-

MI]

• lsp-trace with the DDMAP TLV option of an LDP FEC stitched to a BGP labeled routereturned “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 re-

enter 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 • 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.

This issue has been resolved. [160046-MI]• Power supply alarms are now generated for APEQ faults on the 7750 SR-12e. [164824-MI]

CLI • 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 • 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



Resolved Issues


command. For more details, refer to TA 13-0844. This issue has been resolved. [161775-

MA]

• 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 noerror 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


Filter Policies • 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 snoopedmessages 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]



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 LSA’s 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]

BGP • VPN-IPv4 routes that were flagged as invalid might not have been reflected to all route-

reflector 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 rib-

in (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, anerroneous 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]



Resolved Issues


• When using a credit-control-policy on policers with out-of-credit-action set to change-

service-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]

VPLS • 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 from-

vpls” 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. Thiscaused 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-mss-adjust 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]



Resolved Issues


Cflowd • 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


Appl ication

Assurance

• 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


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]



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 formattedcorrectly. This issue has been resolved. [159602-MI]

CLI • 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 SoftReset (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]

System • 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 disksnow 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]



Resolved Issues


• 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 thefailover 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


IPsec • 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 peer’s 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]

OSPF • 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 config-

ured on each individual secondary interface. [160163-MA]

• 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 best-

effort 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]

BGP • 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



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 “LOGGER-

CRITICAL-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. [156286-

MI]

• 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]

Services General • 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]

Subscriber

Management

• 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:- 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 tonon-DF while the site-activation-timer is running. This issue has been resolved. [151406-

MA]

Appl ication

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 2

32

. This issue has been resolved. [160586-MI]

BFD • BFD packets are no longer subject to the configurable protocol-protection feature. Multi-

hop 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

Aggregat ion

• 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 WLAN-

GW 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]



Resolved Issues


• IP addresses from a NAT pool are distributed over the different MS-ISAs in a wlan-gw-

group. 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 withoutan IP address assigned might have reset when a UE connected. This issue has been

resolved. [159930, 160089-MI]

OAM • 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 • 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 hardwarefailure will now trigger a card reset to automatically recover from this condition. [154898-

MI]

CLI • 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).This issue has been resolved. [156752-MI]

• 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 CPM’s/CFM’s 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 CPM’s/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-group-

redirect 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 wasupdated 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]



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


Subscriber

Management

• 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 out-

of-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-Call-

Connected (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. [156687-

MI]

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 filerecovery, “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

Aggregat ion

• 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]

Resolved in 11.0.R2



CLI • 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-PORT-

MIB 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]

System • 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.R n) on a local compact flash, then redundancy

synchronization would have failed when ran explicitly (e.g., “admin redundancysynchronize 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 IS-

IS 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]



Resolved Issues


BGP • 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

resolved. [154234-MI]• 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, AS-

path-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.


MPLS/RSVP • Roll back was not supported when the “configure router mpls-labels static-labels max-lsp-

labels 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 intra-

area 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]

LDP • 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]

IP Multicast • When max-num-sources was configured in IGMP-snooping (under sap/mesh-sdp/spoke-

sdp), 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


PIM • 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 anmVPN, 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


Filter Policies • 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 redirect-

policy 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, 154833-

MI]

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]



Resolved Issues


• 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 andchassis types. This issue has been resolved. [156188-MA]

WiFi Offload and

Aggregat ion

• 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 beendisplayed 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-GW-group 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]

VPRN/2547 • 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 thedefault 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 con-

fig>router>nat>inside>nat64# prefix 64:ff9b::/96. To get to a consistent state, the NAT64-

node had to be removed (via CLI or SNMP) and recreated (only via CLI). This issue has


• 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 • 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 PTPtiming 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 dot1q-

etype configured at the default value of 0x8100. [154218-MI]



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 time-

stamped at the port, but received packets would have been incorrectly timestamped at theCPM/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]

• 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]

BFD • 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]

Appl ication

Assurance

• 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 • 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 thememory 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. [129129-

MA]

• 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-1gb-

xp-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]



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 mod-

ules (APEQs) automatically turn on power to the SFMs, but the active CPM will power-

cycle them. [139940-MI]

• 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 EFM-

OAM 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 anyother 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 issuehas been resolved. [138054-MI]

• 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]



Resolved Issues


• 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]

System • 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 wasnegative, the values were not properly displayed in “show system thresholds”. This issue


• On rare occasions, retrieving a routing interface’s 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 protocol-

protection 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 ARBtimescale 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. [143828-

MA]• 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-



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]

• 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. Thisoccurred 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


• 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

been resolved. [136419-MI]• 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]

Management • 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 countersthat 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]



Resolved Issues


Routing • The up-time of the local system IP address interface is no longer reset after a High-

Availability 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 triggera 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 next-

hop 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 system’s predefined thresholds. This issue has been


DHCP • 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 mighthave 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



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 source-

address 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 beenresolved. [134221-MA]

• 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

resolved. [143900-MI]• 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]



Resolved Issues


• GRE/IP-IP tunnels should not have been configured to use the same tunnel group as MC-

IPsec 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]

IS-IS • 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 packetsif 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. [149420-

MI]

OSPF • 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. [132590-

MI]

• 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]

• 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 tunnelwas 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 re-

generated, OSPF no longer re-generated all of the opaque LSAs in the area. [150401-MI]

BGP • 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 next-

hop 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-hop-

resolution>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,



Resolved Issues


configured as ASBR with Inter-AS option B, received many BGP-VPN routes with unique

labels. [144474-MA]

• 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 bythe 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. [147338-

MI]

• Support for draft-ietf-idr-optional-transitivehas 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]

MPLS/RSVP • 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 LAGinterface. [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


LDP • 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 activeCPM 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)smight 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. [135920-

MA]

• 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 multicastroute with an invalid PIM next-hop. This issue has been resolved. [152805-MA]

QoS • 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, itcould 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".



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 clearoperation 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 system-

resources”. 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.


• 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 in-

profile 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 blockedafter 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. [150617-

MI]

• 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 HTTP-

redirect 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. [136719-

MI]

• 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]



Resolved Issues


• 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]

Subscriber

Management

• 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. [132995-

MA]

• IPoE-SLAAC host RADIUS QoS override is now applied when instantiated via Access-

Accept 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. [133754-

MI]

• When connection with the RADIUS server was lost and RADIUS fallback was executedupon 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 queue-

instance-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 outerether-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 sla-

profile and the host was in the triggered state while persistency was enabled, if one-time-

http-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 andstates, only the first few hundred would be sync’d initially. The rest would be sync’d 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



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]

• Untagged ARP, DHCP and DHCPv6 packets for subscriber host creation received on a vc-

type “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 thesubscriber 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 HTTP-

redirect 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 LAG’s 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]

• DHCPv4-over-IPv6 transport packets were incorrectly dropped because of draft-ietf-dhc-

dhcpv4-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]

VPLS • 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, static-

mac). 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 whenMAC-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]

VPRN/2547 • 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 wererefreshed 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]



Resolved Issues


• 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 becamereachable 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 next-

hop 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


VRRP/SRRP • 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 been resolved. [144227-MI]

• 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


PPPoE • 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 ledto 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 asnext-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 private-

retail-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]



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 ipfix-

export-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 nat-group 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]

TMS • 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.

The same problem existed when configuring an IGMP snooping mrouter port on a back-

bone B-VPLS SDP. Again, the workaround was to enable IGMP snooping on the I-VPLS

service first.



Resolved Issues


- When booting a Release 9.0 configuration with a mrouter port configured on the B-

VPLS 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 mighthave 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]

• 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. [149999-

MI]

WiFi Offload and

Aggregat ion

• 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 WLAN-

GW. 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]

Appl ication

Assurance

• 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]



Resolved Issues


• 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 workaroundwas 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-high-

wmark" 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 transit-

prefix-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 re-

apply 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 string-

collection 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, someout-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. [142716-

MA]



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, aBFD session could have been wrongly created after a High-Availability CPM/CFM

switchover for the static route with the lower preference. [143775-MI]

OAM • 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 egressnetwork 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]



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. Notethat 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.

HW/Platform • When a differential DS1 on a CEM CMA/MDA is deleted and reconfigured as adifferential 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]

CLI • 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]

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.



Known Issues


• 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 willonly 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 instanceswhere 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]

System • 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 CPU-

protection 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-trap-

group 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



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]

• 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 invalidconfiguration 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 mightcontinue 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. [218559-

MA]

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 looped-

back 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 MC-

APS 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 ofthe 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 trap-

targets pointing to the same address (even if they belong to different trap-groups/logs). This

issue does not affect replay functionality with only one trap-target per trap-receiver

address. [69819-MI]

• The system may not return a lexicographically higher OID than the requested OID in an

SNMP GET-NEXT operation when incorrect values are used. This behavior is seen in the

tcpConnectionTable table. [80594-MI]

• After 497 days, any “Last Change” counter on the system will wrap around due to a 32-bit

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 High-

Availability 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]

DHCP • When a master local DHCP server grants an IP address that has just been released, thefollowing 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, re-

authentication is incorrectly triggered for each renew packet:

- 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]

IS-IS • 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]



Known Issues


• 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” isconfigured. [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]

BGP • Changing the BGP router-id value in a base or VPRN configuration will immediately cause

a flap of all BGP neighbors that are part of that instance. [121246-MI]

• When performing a VPRN configuration change followed by a High-Availability

switchover on the root node of a RSVP or mLDP PMSI, the intra-area BGP-AD routes for

the PMSI are not installed in the root node. The workaround is to clear the BGP neighbor.[134851-MI]

• A 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 update-

fault-tolerance flag is set. [151844-MI]

• Inter-AS Option B and C are not supported between a confederation’s 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, “always-

compare-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 ofthe 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]

• 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]

LDP • 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]



Known Issues


• 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 shortest-

path tree have the same IPv6 link-local address, then the router will be unable to send RTP-

prune messages. [152125-MI]

• In dual-homing PE scenarios where the path from the active source-PE to customer RP

fails and recovers, a customer’s channel (S,G) entry may remain programmed on the PE’s

VRF even if the receiver leaves the group. [152632-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 CPMswitchover. 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


• 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 OutgoingInterface 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].

Filter Policies • 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]

Services General • uRPF and interface statistics may not be correct after an event such as a clear of thestatistics, 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]

Subscriber

Management

• 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 High-

Availability 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-



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]

• Setting up a Diameter peer TCP connection via VPRN is only supported with the defaultTCP 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 High-

Availability switchover. [209325-MA]

VPLS • The per-service hashing feature will not work for egress VPLS management IP traffic in a

VPLS service. [91377-MI]

• CPM- or CFM-originated packets sent on a VPLS management interface are mapped and

treated as NC forwarding class regardless of their DSCP value. [102765-MI]

• In a VPLS using an I-PMSI and a spoke-SDP of vc-type VLAN, when L2PT or BPDU-

translation is enabled on the service and STP BPDUs are received over P2MP leaf, they are

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 from-

vpls” or “mvr to-sap” below the SAP is correctly prevented. However, first configuring

SAP “mvr from-vpls” or “mvr to-sap” and afterwards enabling “allow-ip-int-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]

VPRN/2547 • 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]



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 CE-

originated 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]

Video • 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 forwardedto all MS-ISAs in the group. The recovery action is to re-provision the affected MS-ISAs.

[189479-MA]

WiFi Offload and

Aggregat ion

• 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]

NAT • 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]



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 advisableto 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]

Appl ication

Assurance

• 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 mayexperience 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-



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>cpu-

protection), 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-20V11.0.R20*

93-0446-20 V11.0.R20



Documents

SR OS 11.0.R20 Software release notes