ReleaseNotes:Junos fortheEXSeries,MSeries,MXSeries ... · Hostname: lab Model: ex9208 Junos: ... • OnanEXSeriesswitchthathasboth802.1Xauthentication(dot1x) ... (AAA)(RADIUS)onpage26

Release Notes: Junos®OSRelease 13.3R4

for the EX Series, M Series, MX Series,

PTX Series, and T Series

7 October 2014

Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Junos OS Release Notes for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Layer 3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Resolved Issues: Release 13.3R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Resolved Issues: Release 13.3R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 15

Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . . 15

1Copyright © 2014, Juniper Networks, Inc.

Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D

Universal Edge Routers, and T Series Core Routers . . . . . . . . . . . . . . . . . . . . . 18

New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Authentication, Authorization and Accounting (AAA) (RADIUS) . . . . . . 26

Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55



User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62




Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65



Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Copyright © 2014, Juniper Networks, Inc.2

Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series

MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71


User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73




Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Aggregated Ethernet Interfaces Feature Guide for Routing Devices . . . 106

Chassis-Level Feature Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Class of Service Library for Routing Devices . . . . . . . . . . . . . . . . . . . . . . 110

Dynamic Firewall Feature Guide for Subscriber Services . . . . . . . . . . . . 110

Ethernet Interfaces Feature Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Ethernet Networking Feature Guide for MX Series Routers . . . . . . . . . . . 111

Firewall Filters Feature Guide for Routing Devices . . . . . . . . . . . . . . . . . . 113

Interchassis Redundancy Using Virtual Chassis Feature Guide for MX

Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

IP Demux Interfaces over Static or Dynamic VLAN Demux

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Junos Address-Aware Carrier-Grade NAT and IPv6 Feature Guide . . . . . 114

Layer 2 Configuration Guide, Bridging, Address Learning, and

Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Layer 2 VPNs Feature Guide for Routing Devices . . . . . . . . . . . . . . . . . . . 116

Network Management Administration Guide for Routing Devices . . . . . 116

Protocol Family and Interface Address Properties . . . . . . . . . . . . . . . . . . 117

Services Interfaces Configuration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Standards Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Subscriber Management Feature Guide . . . . . . . . . . . . . . . . . . . . . . . . . 122

System Log Messages Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Unified ISSU System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Virtual Chassis support on MX104 routers . . . . . . . . . . . . . . . . . . . . . . . 124

VPLS Feature Guide for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . 124

VPWS Feature Guide for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . 124

Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . 125

Basic Procedure for Upgrading to Release 13.3 . . . . . . . . . . . . . . . . . . . . 125

Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 128

Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 128

Upgrading Juniper Network Routers Running Draft-Rosen Multicast

VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . 130

Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled

for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Downgrading from Release 13.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133


Changes Planned for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Junos OS Release Notes for PTX Series Packet Transport Routers . . . . . . . . . . . 135

New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137



Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 140


Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141



User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144


MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Resolved Issues: Release 13.3R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145



Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Network Management Administration Guide for Routing Devices . . . . . 151

VPWS Feature Guide for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . 151

Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 151

Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 152

Basic Procedure for Upgrading to Release 13.3 . . . . . . . . . . . . . . . . . . . . 152

Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Third-Party Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158



Introduction

Junos OS runs on the following Juniper Networks®hardware: ACX Series, EX Series, J

Series, M Series, MX Series, PTX Series, QFabric, QFX Series, SRX Series, and T Series.

These release notes accompany Junos OS Release 13.3R4 for the EX Series, M Series,

MXSeries,PTXSeries, andTSeries.Theydescribenewandchanged features, limitations,

and known and resolved problems in the hardware and software.

Junos OS Release Notes for EX Series Switches

These releasenotesaccompany JunosOSRelease 13.3R4 for theEXSeries. Theydescribe

newandchanged features, limitations, andknownand resolvedproblems in thehardware

and software.

You can also find these release notes on the Juniper Networks Junos OS Documentation

webpage, located at http://www.juniper.net/techpubs/software/junos/.

• New and Changed Features on page 5

• Changes in Behavior and Syntax on page 7

• Known Behavior on page 9

• Known Issues on page 9

• Resolved Issues on page 11

• Documentation Updates on page 15

• Migration, Upgrade, and Downgrade Instructions on page 15

• Product Compatibility on page 16

New and Changed Features

This section describes the new features and enhancements to existing features in Junos

OS Release 13.3R4 for the EX Series.

• Hardware

• Infrastructure

• Multicast

• NetworkManagement andMonitoring

• OpenFlow


Introduction

http://www.juniper.net/techpubs/software/junos/

Hardware

• Extended cablemanager for EX9214 switches—An extended cable manager is nowavailable for EX9214 switches. The extended cablemanager allows you to route cables

away from the front of the line cards and Switch Fabric modules and provides easier

access to the switch than the standard cable manager. To obtain the extended cable

manager, order the MX960 Enhanced Cable Manager, ECM-MX960. (Note that

installation of the extended cable manager must be done by a Juniper-authorized

technician and that the service cost is in addition to the component cost.) SeeMX960

Cable Manager Description .

Infrastructure

• Support for IPv6 forTACACS+authentication (EX9200)—StartingwithRelease 13.3,Junos OS supports IPv6 along with the existing IPv4 support for user authentication

using TACACS+ servers.

Multicast

• MLD snooping on EX9200 switches—EX9200 switches support MLD snooping.Multicast Listener Discovery (MLD) snooping constrains the flooding of IPv6multicast

traffic on VLANs on a switch. When MLD snooping is enabled on a VLAN, the switch

examinesMLDmessages between hosts andmulticast routers and learnswhich hosts

are interested in receiving traffic for a multicast group. Based on what it learns, the

switch then forwards multicast traffic only to those interfaces in the VLAN that are

connected to interested receivers instead of flooding the traffic to all interfaces. You

configure MLD snooping at either the [edit protocols] hierarchy level or the [edit

routing-instances routing-instance-name protocols] hierarchy level. See Understanding

MLD Snooping.

NetworkManagement andMonitoring

• sFlowtechnologyonEX9200switches—EX9200switchessupportsFlowtechnology,a monitoring technology for high-speed switched or routed networks. The sFlow

monitoring technology randomly samples network packets and sends the samples to

amonitoring station. You can configure sFlow technology on an EX9200 switch to

continuously monitor traffic at wire speed on all interfaces simultaneously. The sFlow

technology is configuredat the[editprotocolssflow]hierarchy level. SeeUnderstanding

How to Use sFlow Technology for Network Monitoring on an EX Series Switch.

OpenFlow

• Support for OpenFlow v1.0—Starting with Junos OS Release 13.3, EX9200 switchessupport OpenFlow v1.0. You use the OpenFlow remote controller to control traffic in

an existing network by adding, deleting, andmodifying flows on switches. You can

configure oneOpenFlow virtual switch and one activeOpenFlow controller at the [edit

protocols openflow] hierarchy level on each device running Junos OS that supports

OpenFlow. See Understanding Support for OpenFlow on Devices Running Junos OS.



http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/cable-management-system-mx960.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/cable-management-system-mx960.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/mld-snooping-overview-l2.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/mld-snooping-overview-l2.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/sflow-ex-series.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/sflow-ex-series.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/junos-sdn-openflow-support-overview.html

RelatedDocumentation

Changes in Behavior and Syntax on page 7•







Changes in Behavior and Syntax

This section lists the changes in behavior of JunosOS features and changes in the syntax

of JunosOS statements and commands from JunosOSRelease 13.3R4 for the EXSeries.

• Interfaces and Chassis on page 7

• User Interface and Configuration on page 7

Interfaces and Chassis

• On EX9200 switches, the arp-l2-validate command provides a workaround for issues

related to MAC and ARP entries going out of sync in an MC-LAG scenario. Use the

commandtocorrectmismatchesbetweenMACandARPentries related to thenext-hop

interface.

• On EX9200 switches, the following CLI commands have been added to the output of

the request support information CLI command:

• show ethernet-switching interface detail

• show ethernet-switching table

• show spanning-tree bridge detail

• show spanning-tree interface

• show vlans extensive

• show vrrp summary

User Interface and Configuration

• Change in show version command output on EX9200 switches—Beginning in JunosOS Release 13.3, the show version command output includes the new Junos field that

displays the Junos OS version running on the device. This new field is in addition to the

list of installed sub-packages running on the device that also display the Junos OS

version number of those sub-packages. This field provides a consistent means of

identifying the Junos OS version, rather than extracting that information from the list

of installed sub-packages. In the future, the list of sub-packages might not be usable

for identifying the JunosOS version running on the device. This change in outputmight

impact existing scripts that parse information from the show version command.



In Junos OS Release 13.2 and earlier, the show version command does not have the

single Junos field in theoutput thatdisplays the JunosOSversion runningon thedevice.

The only way to determine the Junos OS version running on the device is to review the

list of installed sub-packages.

Junos OS Release 13.3 and Later ReleasesWith the JunosField

Junos OS Release 13.2 and Earlier ReleasesWithout theJunos Field

user@switch> show versionHostname: lab Model: ex9208 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...

user@switch> show versionHostname: lab Model: ex9208 JUNOS Base OS boot [12.3R2.5]JUNOS Base OS Software Suite [12.3R2.5]JUNOS Kernel Software Suite [12.3R2.5]JUNOS Crypto Software Suite [12.3R2.5]...

[See show version.]

• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in theCLI—JunosOS reserves theprefix junos- for the identifiers of configurationsdefinedwithin the junos-defaults configuration group. User-defined identifiers cannot

startwith the string junos-. If you configureduser-defined identifiers using the reserved

prefix through a NETCONF or Junos XML protocol session, the commit would correctly

fail. Prior to Junos OS Release 13.3, if you configured user-defined identifiers through

the CLI using the reserved prefix, the commit would incorrectly succeed. Junos OS

Release 13.3R1 and later releases now exhibit the correct behavior. Configurations that

currently contain the reserved prefix for user-defined identifiers other than

junos-defaults configuration group identifiers will now correctly result in a commit

error in the CLI.

• Configuring regularexpressions(EX9200)—Inall supported JunosOSreleases, regularexpressions can no longer be configured if they require more than 64MB of memory

or more than 256 recursions for parsing.

This change in the behavior of Junos OS is in line with the FreeBSD limit. The change

wasmade in response to a known consumption vulnerability that allows an attacker

to cause a denial of service (resource exhaustion) attack by using regular expressions

containing adjacent repetition operators or adjacent bounded repetitions. Junos OS

uses regular expressions in several placeswithin theCLI. Exploitationof this vulnerability

can cause the Routing Engine to crash, leading to a partial denial of service. Repeated

exploitation can result in an extendedpartial outageof services providedby the routing

protocol process (rpd).


New and Changed Features on page 5•







http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-version.html



Known Behavior

This section lists known behaviors, systemmaximums, and limitations in hardware and

software in Junos OS Release 13.3R4 for the EX Series.

For the most complete and latest information about known Junos OS defects, use the

Juniper Networks online Junos Problem Report Search application.

• OpenFlow

OpenFlow

• OnEX9200switches, configurationofa firewall filteronanOpenFlow-enabled interface

is not supported.









Known Issues

This section lists the known issues in hardware and software in Junos OSRelease 13.3R4

for the EX Series.



• Infrastructure

• Interfaces and Chassis

• Layer 3 Features

• Multicast

• NetworkManagement andMonitoring

• OpenFlow

• Platform and Infrastructure

• Software Installation and Upgrade


Known Behavior

http://prsearch.juniper.net


Infrastructure

• OnEX9200 switches, in a Layer 2 environment, transit packetswith a size of 1514MTU

might get dropped silently when the packets exit from a trunk interface without VLAN

tagging or flexible VLAN tagging enabled. PR960638


• On EX9200 switches, an LLDP neighbor might not be formed for Layer 3-tagged

interfaces even though peer switches are able to form the neighbor. PR848721

Layer 3 Features

• On EX9200 switches, BFD on IRB interfaces flaps if BFD is configured for subsecond

timers. PR844951

Multicast

• If you configure a large number of PIM source-specific multicast (SSM) groups on an

EX9200switch, the switchmight experienceperiodic IPv6 traffic loss. Asaworkaround,

configure the pim-join-prune-timeout value on the last-hop router as 250 seconds.

PR853586


• OnEX9200switches, even if youconfigureanegress sampling rate for sFlowmonitoring

technology, the switch uses the ingress sampling rate instead. PR686002

OpenFlow

• OnEX9200switches, aBGPsessionmight flapwhenanOpenFlow interface is receiving

line-rate traffic and the traffic is notmatching any rule, and therefore thedefault action

of packet-in is applied. PR892310

• OnEX9200 switches,minormemory leaksmight occur if you add anddelete the same

multi-VLAN flow on the order of 100,000 such add and delete operations. PR905620

Platform and Infrastructure

• OnEX9200switches, the showethernet-switching tablevlan-namevlan-name | display

xmlCLI commanddoesnothave thevlan-nameattribute in the<l2ng-l2ald-rtb-macdb>

xml tag. PR955910

• On EX9200 switches, when apply-groups is used in the configuration, the expansion

of interfaces <*> apply-groups is done against all interfaces during the configuration

validation process, even if the apply-group is configured only under a specific interface

stanza. This does not affect the configuration—if the configuration validation passes,

the apply-groups are expanded correctly only against the interfaces where the

apply-groups are configured. PR967233



http://prsearch.juniper.net/PR960638









Software Installation and Upgrade

• When you are upgrading the software on an EX9200 switch, the following warning

messagemight be displayed: Could not open requirements file for jroute-ex:

/etc/db/pkg/jroute-ex/+REQUIRE. You can ignore this message. PR924106









Resolved Issues

This section lists the issues fixed in the Junos OS Release 13.3 main release and the

maintenance releases.


Juniper online Junos Problem Report Search application.

• Resolved Issues: Release 13.3R4 on page 11



Resolved Issues: Release 13.3R4

Dynamic Host Configuration Protocol (DHCP)

• On an EX9200 switch acting as a DHCP relay agent, DHCP_ACKmessages sent from

aDHCP servermight not get forwarded to the client if the server identifier in the DHCP

packet is different from that in the DHCP relay agent’s binding table. PR994735

Multicast

• On EX9200 switches that are configured in a multicast scenario with PIM enabled, an

(S,G) discard route might stop programming if the switch receives resolve requests

from an incorrect reverse-path-forwarding (RPF) interface. After this issue occurs, the

(S,G) state might not be updated when the switch receives multicast traffic from the

correct RPF interfaces, andmulticast traffic might be dropped. PR1011098


• Onan EX9200 switch, if the underlying Layer 2 interface of an IRB interface is changed

from accessmode to trunkmode and bi-directional traffic is sent from an interface on

the same switch that has been changed from IRB over Layer 2 to Layer 3 mode, the


Resolved Issues



prsearch.juniper.net/PR994735


Layer 3 traffic toward the IRB interface might be dropped and PPE thread timeout

errors might be displayed. PR995845

• On EX9200 switches, if you configure the interface alias feature, the featuremight not

work as expected and interfaces might go up and down after commit. PR981249

Routing Protocols

• On an EX9200 switch with an IGMP configuration in which two receivers are joined to

the same (S,G) and IGMP immediate-leave is configured, when one of the receivers

sends a leavemessage for the (S,G), the other receiver might not receive traffic for 1-2

minutes.PR979936


Authentication and Access Control

• On an EX Series switch that has both 802.1X authentication (dot1x) and a dynamic

firewall filter enabled,when the server-timeout value is set toa short time (for example,

3 seconds), if a large number of clients try to authenticate at the same time, a delay

success authentication success messagemight be received on the switch because of

a RADIUS server timeout, and the firewall filter might corrupt the interfaces on which

theauthenticationattemptsweremade,becauseofwhichclientauthenticationsmight

fail. As aworkaround, configure a server-timeout value that is greater than 30 seconds.

PR967922

Bridging and Learning

• OnEX9200 switches onwhich a native VLAN is configured on a link aggregation group

(LAG), if the native VLAN is changed, for example, if the native VLAN ID is changed or

if the native VLAN is disabled, a packet forwarding engine (PFE) thread timeoutmight

occur and LU chip error messages might be displayed. Traffic might be affected.

PR993080

Dynamic Host Configuration Protocol

• OnEX9200switches thatare configuredasaDHCP relayor server over an IRB interface,

the relay and server binding tables might incorrectly display the name of the IRB

interfaceas thenameof thephysical interface. Youcanuse the showdhcp relaybinding

detail and show dhcp server binding detail commands to display the correct name of

the physical interface. PR972346

• On an EX9200 switch where a binding already exists for a client, if the client sends a

DHCPdiscovermessage, the switchmight not relay DHCPoffers fromany server other

than the server used to establish the existing binding. PR974963


• On EX9200 switches, the configuration statementmcae-mac-flush is not available in

the CLI; it is missing from the [edit vlans] hierarchy level. PR984393











• On EX9200 switches that have amultichassis link aggregation group (MC-LAG)

interfaces configured by using themac-rewrite statement, the Layer 2 address learning

process (l2ald) might crash, creating a core file. PR997978

OpenFlow

• OpenFlow v1.0 running on an EX9200 switch does not respond reliably to interface up

or down events within a specified time interval. Per a fix implemented in Junos OS

Release 13.3R3.6, OpenFlow v1.0 running on an EX9200 switch responds reliably to

interface up or down events if the echo interval timeout is set to 11 seconds or more.

PR989308


• On an EX9200 switch working as a DHCP server, when you delete an IRB interface or

change the VLAN ID of a VLAN corresponding to an IRB interface, the DHCP process

(jdhcpd) might create a core file after commit because a stale interface entry in the

jdhcpd database has been accessed. PR979565

Routing Protocols

• On EX9200 switches with IGMP snooping enabled on an IRB interface, some transit

TCP packets might be treated as IGMP packets, causing packets to be dropped.

PR979671


• When you are upgrading the software on an EX9200 switch, the following warning

messagemight be displayed: Could not open requirements file for jroute-ex:

/etc/db/pkg/jroute-ex/+REQUIRE. You can ignore this message. PR924106

Spanning-Tree Protocols

• On EX9200 switches, the MSTI identifier range for MSTP is limited to 1-64 while it

should be 1-4094. PR846878


Bridging and Learning

• On EX9200 switches, trunk configuration [edit interface interface-name unit 0 family

ethernet-switching interface-mode trunk]might not work as expected, causing traffic

loss. PR963175

Dynamic Host Configuration Protocol

• On an EX9200 switch that is configured for DHCP relay, with the switch acting as the

DHCPrelayagent, theswitchmightnotbeable to relaybroadcastDHCP informpackets,

which are used by the client to getmore information from theDHCP server.PR946038

• On EX9200 switches with Dynamic Host Configuration Protocol (DHCP) relay

configured, permanent Address Resolution Protocol (ARP) entries for relay clients are

installed. When the client is reachable via a different preferred path (due to STP


Resolved Issues









topologychangesorMC-LAGchangesandsoon), the forwardingstate isnot refreshed.

This might cause packets to be dropped until the relay binding is cleared. PR961479

• OnanEX9200switch thatworksasaDHCP relayagent, if the switch receivesbroadcast

DHCPACKpackets sentbyanotherDHCPrelay switch, thosepacketsmightbedropped

until the DHCPmax-hop limit is reached. PR961520

Infrastructure

• OnEX9200 switcheswith an EX9200-32XS line card or an EX9200-2C-8XS line card,

10-gigabit ports on the line card might stay offline if a link flaps or an SFP+ is inserted

after the links have been up for more than 3months. PR905589

• On an EX Series Virtual Chassis that is configured for DHCP services and configured

with a DHCP server, when a client sends DHCP INFORM packets and then the same

client sends the DHCP RELEASE packet, an IP address conflict might result because

the same IP address has been assigned to two clients. As a workaround:

• 1. Clear the binding table:

user@switch> clear system services dhcp binding

• 2. Restart the DHCP service:

user@switch> restart dhcp

PR953586

• On an EX9200 switch, when the SNMPmib2d daemon polls system statistics from

the kernel, the kernel might cause amemory leak (mbuf leak), which in turn might

cause packets such as ARP packets to be dropped at the kernel. PR953664

• On an EX9200 switch with scaled ARP entries (for example, 48K entries), in a normal

state, an ARP entry's current timemust be less than the expiry time. However, some

events might cause the current time to be greater than the expiry time, which would

then not allow the ARP entry to be flushed and thus would lead to connectivity issues.

A possible trigger event could be an Inter-Chassis Link flap in a multichassis link

aggregation group scenario. PR963588


• OnEX9200 switches, an inter-IRB routemight notwork if Q-in-Q tunneling is enabled,

because theTPID (0x9100) is not setonegressdual-taggedpackets, andotherdevices

that receive these untagged packets might drop them. PR942124

• On an EX Series switch, if you remove an SFP+ and then add it back or reboot the

switch, and the corresponding disabled 10-gigabit interface is amember of a LAG, the

link on that port might be activated. PR947683











Virtual Chassis

• OnEX9200Virtual Chassis, the showvirtual-chassis vc-portcommand showsa resync

flag as part of the Status column of the command. The resync flag indicates the

forwarding readinessof thePacket ForwardingEngine (onwhichVCPsare configured),

once it is up after a reboot. PR946920









Documentation Updates

There are no errata or changes in Junos OS Release 13.3R4 for the EX Series switches

documentation.









Migration, Upgrade, and Downgrade Instructions

This section contains upgrade and downgrade policies for Junos OS for the EX Series.

Upgrading or downgrading Junos OS can take several hours, depending on the size and

configuration of the network.

• Upgrade and Downgrade Support Policy for Junos OS Releases on page 15

Upgrade and Downgrade Support Policy for Junos OS Releases

Support for upgrades and downgrades that spanmore than three Junos OS releases at

a time is not provided, except for releases that are designated as Extended End-of-Life

(EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can

upgrade directly from one EEOL release to the next EEOL release, even though EEOL

releases generally occur in increments beyond three releases.




You can upgrade or downgrade to the EEOL release that occurs directly before or after

the currently installed EEOL release, or to twoEEOL releases before or after. For example,

JunosOSReleases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from JunosOS

Release 10.0 toRelease 10.4 or even from JunosOSRelease 10.0 toRelease 11.4. However,

you cannot upgrade directly from a non-EEOL release that is more than three releases

ahead or behind. For example, you cannot directly upgrade from Junos OS Release 10.3

(a non-EEOL release) to Junos OS Release 11.4 or directly downgrade from Junos OS

Release 11.4 to Junos OS Release 10.3.

To upgrade or downgrade fromanon-EEOL release to a releasemore than three releases

before or after, first upgrade to the next EEOL release and then upgrade or downgrade

from that EEOL release to your target release.

For more information about EEOL releases and to review a list of EEOL releases, see

http://www.juniper.net/support/eol/junos.html .

For information on software installation and upgrade, see the Installation and Upgrade

Guide.









Product Compatibility

• Hardware Compatibility on page 16

Hardware Compatibility

To obtain information about the components that are supported on the devices, and

special compatibility guidelineswith the release, see theHardwareGuide for theproduct.

Todetermine the features supportedonEXSeries switches in this release, use the Juniper

Networks Feature Explorer, a Web-based application that helps you to explore and

compare Junos OS feature information to find the right software release and hardware

platform for your network. Find Feature Explorer at:

http://pathfinder.juniper.net/feature-explorer/








http://www.juniper.net/support/eol/junos.html

http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/software-installation-and-upgrade/software-installation-and-upgrade.html








JunosOSReleaseNotesforMSeriesMultiserviceEdgeRouters,MXSeries3DUniversalEdge Routers, and T Series Core Routers

These release notes accompany Junos OS Release 13.3R4 for the M Series, MX Series,

and T Series. They describe new and changed features, limitations, and known and

resolved problems in the hardware and software.













OS Release 13.3R4 for the M Series, MX Series, and T Series.

• Hardware on page 19

• Authentication, Authorization and Accounting (AAA) (RADIUS) on page 26

• Class of Service (CoS) on page 26

• General Routing on page 28

• High Availability (HA) and Resiliency on page 29


• IPv6 on page 37

• Layer 2 Features on page 37

• MPLS on page 37

• Multicast on page 38

• Network Management and Monitoring on page 38

• OpenFlow on page 39

• Platform and Infrastructure on page 39

• Port Security on page 39

• Routing Policy and Firewall Filters on page 40

• Routing Protocols on page 41

• Services Applications on page 42

• Software Installation and Upgrade on page 43




• Subscriber Management and Services on page 43

• VPNs on page 49

Hardware

• MIC support (MX104)—Junos OS Release 13.3 and later releases extend support tothe following MICs on the MX104 3D Universal Edge Routers:

• ATMMICwith SFP (Model No: MIC-3D-8OC3-2OC12-ATM)

• DS3/E3MIC (Model No: MIC-3D-8DS3-E3)

• Channelized SONET/SDHOC3/STM1 (Multi-rate) MICs with SFP (Model No:

MIC-3D-4CHOC3-2CHOC12)

• Channelized SONET/SDHOC3/STM1 (Multi-rate) MICs with SFP (Model No:

MIC-3D-8CHOC3-4CHOC12)

• Multiservices MIC (Model No: MS-MIC-16G)

• SONET/SDHOC3/STM1 (Multi-rate) MICs with SFP (Model No:

MIC-3D-4OC3OC12-10C48)

• SONET/SDHOC3/STM1 (Multi-rate) MICs with SFP (Model No:

MIC-3D-8OC3OC12-4OC48)

• SONET/SDHOC192/STM64MICs with XFP (Model No: MIC-3D-10C192-XFP)

[SeeMICs Supported by MX Series Routers in theMX Series Interface Module Reference.]

• Support for MICs onMPC3E (MX240, MX480, andMX960)—Starting in Junos OSRelease 13.3, the following MICs are supported on the MPC3E (MX-MPC3E-3D):

• SONET/SDHOC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-8OC3OC12-4OC48)

• SONET/SDHOC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-4OC3OC12-1OC48)

• SONET/SDHOC192/STM64MIC with XFP (MIC-3D-1OC192-XFP)

• DS3/E3 MIC (MIC-3D-8DS3-E3)

The following encapsulations are supported on the aforementioned MICs on MPC3E:

• Cisco High-Level Data Link Control (cHDLC)

• Flexible Frame Relay

• Frame Relay

• Frame Relay for circuit cross-connect (CCC)

• Frame Relay for translational cross-connect (TCC)

• MPLS fast reroute

• MPLS CCC

• MPLS TCC

• Point-to-Point Protocol (PPP) (default)

• PPP for CCC



http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-atm-oc3-oc12.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-ds3-e3.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-chan-sonet-sdh-oc3-multirate-sfp.html




http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-ms.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-sonet-sdh-oc3-multirate-sfp.html




http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-oc192-xfp.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-supported.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/mx-series/common/line-card-guide/mx-series-line-card-guide.pdf

• PPP for TCC

• PPP over Frame Relay

[SeeMPC3E onMX Series Routers Overview.]

• CFP-GEN2-CGE-ER4 (MX Series, T1600, and T4000)—The CFP-GEN2-CGE-ER4transceiver (part number: 740-049763) provides a duplex LC connector and supports

the 100GBASE-ER4 optical interface specification andmonitoring. Starting in Junos

OSRelease 13.3, the “GEN2”opticshavebeen redesignedwithnewer versionsof internal

components for reducedpower consumption.The following interfacemodules support

the CFP-GEN2-CGE-ER4 transceiver. For more information about interface modules,

see the Interface Module Reference for your router.

MX Series routers:

• 100-Gigabit Ethernet MIC with CFP (model number:

MIC3-3D-1X100GE-CFP)—Supported in Junos OS Release 12.1R1 and later

• 2x100GE + 8x10GEMPC4E (model number: MPC4E-3D-2CGE-8XGE)—Supported

in Junos OS Release 12.3R2 and later

T1600 and T4000 routers:

• 100-Gigabit Ethernet PIC with CFP (model numbers: PD-1CE-CFP-FPC4 and

PD-1CGE-CFP)—Supported in Junos OS Releases 12.3R5, 13.2R3, 13.3R1, and later

[See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications.]

• SFP-GE80KCW1470-ET, SFP-GE80KCW1490-ET, SFP-GE80KCW1510-ET,SFP-GE80KCW1530-ET, SFP-GE80KCW1550-ET, SFP-GE80KCW1570-ET,SFP-GE80KCW1590-ET, and SFP-GE80KCW1610-ET (MX Series)—Beginning withJunos OS Release 13.3, these transceivers provide a duplex LC connector and support

operationandmonitoringwith linksup toadistanceof80km.Each transceiver is tuned

to a different transmit wavelength for use in CWDM applications. These transceivers

are supported on the following interfacemodule. Formore information about interface

modules, see the Interface Module Reference for your router.

• Gigabit Ethernet MIC with SFP (model number: MIC-3D-20GE-SFP) in all versions

of MX-MPC1, MX-MPC2, and MX-MPC3—Supported in Junos OS Release 12.3R5,

13.2R3, 13.3R1, and later.

[See Gigabit Ethernet SFP CWDMOptical Interface Specification]

• CFP-GEN2-100GBASE-LR4 (T1600 and T4000)—The CFP-GEN2-100GBASE-LR4transceiver (part number: 740-047682) provides a duplex LC connector and supports

the 100GBASE-LR4 optical interface specification andmonitoring. Starting in Junos

OSRelease 13.3, the “GEN2”opticshavebeen redesignedwithnewer versionsof internal

components for reducedpower consumption.The following interfacemodules support

the CFP-GEN2-100GBASE-LR4 transceiver. For more information about interface

modules, see the Interface Module Reference for your router.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/chassis-mpc-100-gigabit-ethernet-mpc-overview.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-100gebase-optical-specifications.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-mx-series-sfp-cwdm.html

• 100-Gigabit Ethernet PIC with CFP (model numbers: PD-1CE-CFP-FPC4 and

PD-1CGE-CFP)—Supported in Junos OS Releases 12.3R5, 13.2R3, 13.3R1, and later


• Software feature support on theMPC5E— Starting in Junos OS Release 13.3, MPC5E

supports the following key features:

• Basic Layer 2 features and virtual private LAN services (VPLS) functionality

• Class of service (CoS)

• Flexible Queuing option—By using an add-on license, MPC5E supports a limited

number of queues (32,000 queues per slot including ingress and egress)

• Hierarchical QoS

• Intelligent oversubscription services

• Interoperability with existing MPCs and DPCs

• MPLS

• MX Virtual Chassis

The following features are not supported on MPC5E:

• Active flowmonitoring and services

• Subscriber management features

[SeeProtocols andApplications Supported by theMX240,MX480,MX960,MX2010, and

MX2020MPC5E.]

• SoftwarefeaturesupportontheMPC5EQ—Starting in JunosOSRelease 13.3,MPC5EQ

supports 1 million queues per slot on all MX Series routers. All the other software

features supported on MPC5E are also supported on MPC5EQ.


MX2020MPC5E.]

• Support for new 520-gigabit full duplex Modular Port Concentrator (MPC6E) withtwoModular InterfaceCard (MIC) slots onMX2010andMX20203DUniversal EdgeRouters—In Junos OS Release 13.3R3 and later, MX2020 andMX2010 routers supportanewMPC,MPC6E(model number:MX2K-MPC6E).MPC6E is a 100-Gigabit Ethernet

MPC that provides increased density and performance to MX Series routers in

broadband access networks for services such as Layer 3 peering, VPLS and Layer 3

aggregation, and video distribution.

MPC6Eprovides packet-forwarding services that deliver up to 520Gbps of full-duplex

traffic. It has two separate slots forMICs and supports four Packet Forwarding Engines

with a throughput of 130Gbps per Packet Forwarding Engine. It also supports twoMIC

slots asWAN ports that provide physical interface flexibility.

MPC6E supports:

• Forwarding capability of up to 130 Gbps per Packet Forwarding Engine

• 100-Gigabit Ethernet interfaces




http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-mpc5e-features-1.html




• Up to 560 Gbps of full-duplex traffic for the twoMIC slots

• WAN-PHYmode on 10-Gigabit Ethernet interfaces on a per port basis

• Two separate slots for MICs (MIC6-10G and MIC6-100G-CXP)

• Two Packet Forwarding Engines for each MIC slot



MX2020MPC5E.]

• FeaturesupportonMPC6E—MPC6Esupports the followingsoftware features in JunosOS Release 13.3R2:

• Basic Layer 2 features and virtual private LAN service (VPLS) functionality, except

for Operation, Administration, and Maintenance (OAM)

• Layer 3 routing protocols

• MPLS

• Multicast forwarding

• Firewall filters and policers

• Class of service (CoS)

• Tunnel service

• Interoperability with existing DPCs and MPCs

• Internet Group Management Protocol (IGMP) snooping with bridging, integrated

routing and bridging (IRB), or VPLS

• Intelligent hierarchical policers

• Layer 2 trunk port

• MPLS-fast reroute (FRR) VPLS instance prioritization

• Precision Time Protocol (PTP) (IEEE 1588)

• Synchronous Ethernet

The following features are not supported on MPC6E:

• Fine-grained queuing and input queuing

• Unified in-service software upgrade (ISSU)

• Active flowmonitoring and services

• Virtual Chassis support


MX2020MPC5E.]

• Support for fixed-configurationMPC onMX240, MX480, MX960, MX2010, andMX2020 routers—MX2020, MX2010, MX960, MX480, and MX240 routers support anewMPC, MPC5E (model number: MPC5E-40G10G). On the MX2010 and MX2020







routers, MPC5E is housed in an adapter card. MPC5E is a fixed-configurationMPCwith

four built-in PICs and does not contain separate slots for Modular Interface Cards

(MICs). MPC5E supports two Packet Forwarding Engines, PFEO and PFE1. PFE0 hosts

PIC0 and PIC2while PFE1 hosts PIC1 and PIC3. A maximum of two PICs can be kept

powered on (PIC0 or PIC2 and PIC1 or PIC3). The other PICs are required to be kept

powered off.

MPC5E supports:

• Flexible queuing option by using an add-on license

• Forwarding capability of up to 130 Gbps per Packet Forwarding Engine


• Quad small form-factor pluggable plus transceivers (QSFP+) and small form-factor

pluggable plus transceivers (SFP+) for connectivity

• Up to 240 Gbps of full-duplex traffic

• WAN-PHYmode on 10-Gigabit Ethernet Interfaces on a per-port basis

Formore informationabout thesupportedandunsupported JunosOSsoftware features

for this MPC, see Protocols and Applications Supported by theMX240, MX480, MX960,

MX2010, and MX2020 MPC5E.

• Support for new fixed-configuration queuingMPC onMX240, MX480, MX960,MX2010, andMX2020 routers—MX2020, MX2010, MX960, MX480, and MX240routers support a new queuing MPC, MPC5EQ (model number: MPC5EQ-40G10G).

On theMX2010 andMX2020 routers, MPC5EQ is housed in an adapter card. MPC5EQ,

like MPC5E, is a fixed-configuration MPCwith four built-in PICs and does not contain

separate slots for Modular Interface Cards (MICs). MPC5EQ, like MPC5E supports two

Packet ForwardingEngines,PFEOandPFE1.PFE0hostsPIC0andPIC2whilePFE1hosts

PIC1 andPIC3. Amaximumof twoPICs can be kept powered on (PIC0 orPIC2 andPIC1

or PIC3). The other PICs are required to be kept powered off.

MPC5EQ supports 1 million queues per slot on all MX Series routers. All the other

software features supported on MPC5E are also supported on MPC5EQ.

Formore informationabout thesupportedandunsupported JunosOSsoftware features

for this MPC, see Protocols and Applications Supported by theMX240, MX480, MX960,

MX2010, and MX2020 MPC5E.

• Support forOTNMIConMPC6E(MX2010andMX2020routers)—Startingwith JunosOS Release 13.3R3, the 24-port 10-Gigabit Ethernet OTNMIC with SFPP

(MIC6-10G-OTN) is supported on MPC6E on the MX2010 and MX2020 routers. The

OTNMIC supports both LAN PHY andWAN PHY framingmodes on a per-port basis.

The MIC supports the following features:

• Transparent transport of 24 10-Gigabit Ethernet signals with optical channel data

unit 2 (ODU2) and ODU2e framing on a per port basis

• ITU-standard optical transport network (OTN) performancemonitoring and alarm

management



• Pre-forwarderror correction (pre-FEC)-basedbit error rate (BER). Fast reroute (FRR)

uses the pre-FEC BER as an indication of the condition of an OTN link

To configure the OTN options for this MIC, use the set otn-options statement at the

[edit interfaces interfaceType-fpc/pic/port] hierarchy level.

• OTNsupport for 10-GigabitEthernetand 100-GigabitEthernet interfacesonMPC5EandMPC6E (MX240, MX480, MX960, MX2010, andMX2020 routers)—Junos OSRelease 13.3 extends optical transport network (OTN) support for 10-Gigabit Ethernet

and 100-Gigabit Ethernet interfaces on MPC5E and MPC6E. MPC5E-40G10G and

MPC5EQ-40G10GsupportOTNon10-GigabitEthernet interfaces,andMPC5E-100G10G

andMPC5EQ-100G10GsupportOTNon 10-GigabitEthernet interfacesand 100-Gigabit

Ethernet interfaces. The OTNMICs MIC6-10G-OTN and MIC6-100G-CFP2 on MPC6E

support OTN on 10-Gigabit Ethernet interfaces and 100-Gigabit Ethernet interfaces,

respectively.

OTN support includes:

• Transparent transport of 10-Gigabit Ethernet signals with optical channel transport

unit 2 (OTU2) framing

• Transparent transport of 100-Gigabit Ethernet signals with OTU4 framing

• ITU-T standard OTN performancemonitoring and alarmmanagement

Compared with SONET/SDH, OTN provides stronger forward error correction,

transparent transport of client signals, and switching scalability. To configure the OTN

options for the interfaces, use the set otn-options configuration statement at the [edit

interfaces interfaceType-fpc/pic/port] hierarchy level.

• Support for 100 Gigabit-Ethernet OTNMIC onMPC6E (MX2010 andMX2020routers)—Startingwith JunosOSRelease 13.3R3, the 2-port 100-Gigabit EthernetMICwith CFP2 (MIC6-100G-CFP2) is supported on MPC6E. The MIC supports optical

transport network (OTN) features on the 100-Gigabit Ethernet interfaces and also

supports line-rate throughput of 100 Gbps per port.

The following OTN features are supported:

• Transparent transport of 2-port 100-Gigabit Ethernet signals with optical channel

data unit 4 (ODU4) framing for each port

• ITU-standard OTN performancemonitoring and alarmmanagement

• Generic forward error correction (GFEC)

To configure OTN options for this MIC, use the set otn-options statement at the [edit

interfaces interfaceType-fpc/pic/port] hierarchy level.

• Support for MPC5E on SCBE2 (MX Series routers)—Starting with Junos OS Release13.3R3, MPC5E is supported on SCBE2 on MX240, MX480, and MX960 routers.

• Support for enhanced 20-port Gigabit Ethernet MIC (MX5, MX10, MX40, MX80,MX240,MX480,andMX960)—Starting in JunosOSRelease 13.3, anenhanced20-portGigabit EthernetMIC(modelnumberMIC-3D-20GE-SFP-E) is supportedonMXSeries

routers. This enhancedMIC supports up to 20 SFP optical transceiver modules, which

include the following:



• Fiber-optic small form-factor pluggable (SFP) transceivers:

• 1000BASE-LH (model number: SFP-1GE-LH)

• 1000BASE-LX (model number: SFP-1GE-LX)

• 1000BASE-SX (model number: SFP-1GE-SX)

• Copper SFP transceiver:

• 1000BASE-T (model number: SFP-1GE-T)

• Bidirectional SFP transceivers:

• 1000BASE-BX (model number pairs: SFP-GE10KT13R14 with SFP-GE10KT14R13,

SFP-GE10KT13R15 with SFP-GE10KT15R13, SFP-GE40KT13R15 with

SFP-GE40KT15R13)

These optical transceiver modules can be hot-swapped. You can view the enhanced

20-portGigabitEthernetMIC informationbyusing theshowchassishardwarecommand.

• Multiservices MIC support (MX104)—Starting with Junos OS Release 13.3R2, theMultiservices MIC (MS-MIC-16G) is supported on MX104 3D Universal Edge Routers.

TheMultiservicesMIChasanenhancedmemoryof 16GBandprovides improvedscaling

and high performance. Only oneMultiservicesMIC is supported on theMX104 chassis.

The Multiservices MIC supports the following software features:

• Active flowmonitoring and export of flowmonitoring version 9 records, based on

RFC 3954

• IP Security (IPsec) encryption

• Network Address Translation (NAT) for IP addresses

• Port Address Translation (PAT) for port numbers

• Stateful firewallwithpacket inspection—detectsSYNattacks, ICMPandUDPfloods,

and ping-of-death attacks

• Traffic sampling

[SeeMultiservices MIC.]

• SFPP-10G-ZR-OTN-XT (MX Series, T1600, and T4000)—Starting with Junos OSRelease 13.3R3, theSFPP-10G-ZR-OTN-XTdual-rateextendedtemperature transceiver

provides a duplex LC connector and supports the 10GBASE-Z optical interface

specification andmonitoring. The transceiver is not specified as part of the 10-Gigabit

Ethernet standard and is instead built according to ITU-T and Juniper Networks

specifications. In addition, the transceiver supports LAN-PHY andWAN-PHYmodes

and OTN rates and provides a NEBS-compliant 10-Gigabit Ethernet ZR transceiver for

the MX Series interface modules listed here. The following interface modules support

the SFPP-10G-ZR-OTN-XT transceiver:



http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mic-mx-series-ms.html

MX Series:

• 10-Gigabit Ethernet MIC with SFP+ (model number:

MIC3-3D-10XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and

later

• 16-port 10-Gigabit Ethernet (model number: MPC-3D-16XGE-SFPP)—Supported in

Junos OS Release 12.3R5, 13.2R3, 13.3, and later

• 32-port 10-Gigabit Ethernet MPC4E (model number:

MPC4E-3D-32XGE-SFPP)—Supported in JunosOSRelease 12.3R5, 13.2R3, 13.3, and

later

• 2-port 100-Gigabit Ethernet + 8-port 10-Gigabit Ethernet MPC4E (model number:

MPC4E-3D-2CGE-8XGE)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and

later

T1600 and T4000 routers:

• 10-GigabitEthernetLAN/WANPICwithOversubscriptionandSFP+(modelnumbers:

PD-5-10XGE-SFPP and PF-24XGE-SFPP)—Supported in Junos OS Release 12.3R5,

13.2R3, 13.3, and later

• 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (model number:

PF-12XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and later

Formore informationabout interfacemodules, see the “CablesandConnectors” section

in the Interface Module Reference for your router.

[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications.]

Authentication, Authorization and Accounting (AAA) (RADIUS)

• RADIUS functionality over IPv6 for systemAAA—Starting fromRelease 13.3R4, Junos

OS supports RADIUS functionality over IPv6 for system AAA (authentication,

authorization, and accounting) in addition to the existing RADIUS functionality over

IPv4 for system AAA. With this feature, Junos OS users can log in to the router

authenticated through RADIUS over an IPv6 network. Thus, Junos OS users can now

configure both IPv4 and IPv6 RADIUS servers for AAA. To accept the IPv6 source

address, include the source-address statement at the [edit system radius-server IPv6]

hierarchy level. (Note that if an IPv6 RADIUS server is configured without any

source-address, default ::0 is considered as the source address.)

Class of Service (CoS)

• CCCandTCCsupportonFRF.15,FRF.16,andMLPPP interfaces(MXSeries)—Startingwith Release 13.3, Junos OS supports Circuit Cross Connect (CCC) and Translational

Cross Connect (TCC) over Multilink Frame Relay (MLFR) UNI NNI (FRF.16) interface

and TCC over Multilink Frame Relay (MLFR) end-to-end (FRF.15) and Multilink

Point-to-Point Protocol (MLPPP) interfaces. You can implement the cross-connect

over anMPLSnetworkor a local-switchednetwork.Whenyouconfigure cross-connect

over these interfaces, thepeer interfacecanbeofanyof the interface types that support

cross-connect.



http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-10-gigabit-optical-specifications.html

To configure CCC over FRF.16/MFR interfaces, include the following statements under

the [edit interfaces interface-name unit number] hierarchy level:

family ccc {translate-discard-eligible;translate-fecn-and-becn;translate-plp-control-word-de;no-asynchronous-notification;

}

To configure TCC over FRF.15/MLFR, FRF.16/MFR, or MLPPP interfaces, include the

followingconfigurationunder the [edit interfaces interface-nameunitnumber]hierarchy

level:

family tcc {protocols [inet isompls];no-asynchronous-notification;

}

To complete CCC or TCC configurations over the multilink Frame Relay interfaces, you

must also specify the interface name under one of the following hierarchies:

• [edit protocols l2circuit neighbor ip-address] if the switching is done over a Layer 2

circuit.

• [edit protocols connections remote-interface-switch remote-if-sw] if the switching

is done over a remote interface switch.

• [edit protocols connections interface-switch local-if-switch] if the switching is done

using a local switch.

• Support for IPv6 traffic over IPsec tunnels onMS-MICs andMS-MPCs (MXSeries)—Starting with Release 13.3, Junos OS extends IPsec support on MS-MICs andMS-MPCs to IPv6 traffic. IPsec support on MS-MICs and MS-MPCs is limited to the

ESP protocol, and now enables you to configure IPv4 and IPv6 tunnels that can carry

IPv6 as well as IPv4 traffic. To enable IPv6 traffic over an IPsec tunnel, configure an

IPv6 address for the local-gateway statement under the [edit services service-set

service-set-name ipsec-vpn-options] hierarchy level.

• CoS show command enhancements (MX Series)—Starting in Release 13.3, Junos OSextendssupport forCoS showcommandswith theadditionof the showclass-of-service

scheduler-hierarchy interfaceand showclass-of-servicescheduler-hierarchy interface-set

commands. These commands display subscriber class-of-service interface and

interface-set information.

[See show class-of-service scheduler-hierarchy interface and show class-of-service

scheduler-hierarchy interface-set.]

• Traffic schedulingandshaping support forGRE tunnel interfaceoutputqueues (MXSeries)—Beginning with Junos OS Release 13.3, you canmanage output queuing oftraffic entering GRE tunnel interfaces hosted on MIC or MPC line cards in MX Series

routers. Support for the output-traffic-control-profile configuration statement, which

applies an output traffic scheduling and shaping profile to the interface, is extended

to GRE tunnel physical and logical interfaces. Support for the

output-traffic-control-profile-remaining configuration statement, which applies an



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-class-of-service-scheduler-hierarchy-interface.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-class-of-service-scheduler-hierarchy-interface-set.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-class-of-service-scheduler-hierarchy-interface-set.html

output traffic scheduling and shaping profile for remaining traffic to the interface, is

extended to GRE tunnel physical interfaces.

NOTE: Interface sets (sets of interfaces used to configure hierarchical CoSschedulers on supported Ethernet interfaces) are not supported on GREtunnel interfaces.

[See Configuring Traffic Control Profiles for Shared Scheduling and Shaping.]

• New forwarding-class-accounting statement onMX Series routers—Starting in JunosOS Release 13.3R3, new forwarding class accounting statistics can be enabled at the

[edit interfaces interface-name] and the [edit interfaces interface-name unit

interface-unit-number] hierarchy levels. These statistics replace theneed touse firewall

filters for gathering accounting statistics. Statistics can be gathered and displayed for

IPv4, IPv6, MPLS, Layer2 and Other families in ingress, egress, or both directions.

• Support for CoS hierarchical schedulers onMPC5E (MX240, MX480, MX960,MX2010,andMX2020routers)—Starting in JunosOSRelease 13.3R3, class-of-service(CoS) hierarchical schedulers can be configured on MPC5E interfaces. This feature is

supported on egress only.

You can use hierarchical schedulers to define traffic control profiles, which set the

following CoS parameters on a CoS interface:

• Delay buffer rate

• Excess bandwidth

• Guaranteed rate

• Overhead accounting

• Scheduler map

• Shaping rate

General Routing

• Nonstop active routing support for logical systems (MX Series)—Starting in Junos

OSRelease 13.3, this featureenablesnonstopactive routing support for logical systems

using the nonstop-routing option under the [edit logical-systems logical-system-name

routing-options] hierarchy. As a result of extending nonstop active routing support for

logical systems, the logical-systems argument has been appended in some show

operational commands to allow display of status, process, and event details.

• Nonstopactive routing formultipoint labeldistributionprotocol (MSeries,MXSeries,and T Series)—Starting in Junos OS Release 13.3, this feature enables nonstop active

routing for the multipoint label distribution protocol, using the nonstop-routing option

at the [edit routing-options] hierarchy level. Themultipoint label distribution protocol

state, event, and process details can be viewed using the p2mp-nsr-synchronization

flag under trace-options.

[See p2mp-ldp-next-hop.]



http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/cos-configuring-traffic-control-profiles-for-shared-scheduling-and-shaping.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/p2mp-ldp-next-hop.html

The showldpdatabasecommanddisplays theentries in theLabelDistributionProtocol

(LDP) database for master and standby Routing Engines.

[See show ldp database.]

Theshowldpp2mptunnelcommanddisplays theLDPpoint-to-multipoint tunnel table

information.

[See show ldp p2mp tunnel.]

High Availability (HA) and Resiliency

• MXSeries Virtual Chassis support for multichassis link aggregation (MX Seriesrouters with MPCs)—Starting in Junos OS Release 13.3, an MX Series Virtual Chassissupports configuration of multichassis link aggregation (MC-LAG). MC-LAG enables

a device to form a logical link aggregation group interface with two or more other

devices. The MC-LAG devices use the Inter-Chassis Communication Protocol (ICCP)

to exchange control information between twoMC-LAG network devices.

When you configure MC-LAGwith an MX Series Virtual Chassis, the link aggregation

group spans links to two Virtual Chassis configurations. Each Virtual Chassis consists

of two MX Series member routers that form a logical systemmanaged as a single

network element. ICCP exchanges control information between the global master

router (VC-M) of the first Virtual Chassis and the VC-M of the second Virtual Chassis.

NOTE: Internet GroupManagement Protocol (IGMP) snooping is notsupported onMC-LAG interfaces in an MX Series Virtual Chassis.

[See Configuring Multichassis Link Aggregation.]

• TCPauto-merge support in nonstop active routing for short duration hold timers forprotocols (BGP, LDP) (kernel) (M Series, MX Series, and T Series)—Beginning withJunosOSRelease 13.3, TCPauto-merge support in nonstopactive routing for protocols

(BGP, LDP) (kernel) is enabledon theMSeries,MXSeries, andTSeries.Nonstopactive

routing automerge is one of the kernel components of the socket replication. On

switchover, this componentmerges the socket pairs automatically from the secondary

to the primary Routing Engine. Currently, nonstop active routing switchover from

secondary to primary happenswhen rpd issues amerge call for each secondary socket

pair to merge them to a single socket, which can result in a delay. To avoid this delay,

this feature introducesanautomergemodule in thekernel thatdecouples thesecondary

socket merge from rpd and automatically merges secondary sockets on switchover

so that the rpd high priority thread takes advantage of this and generates faster

keep-alive to sustain TCP connections on switchover.

• Nonstop active routing support for BGP addpath (M Series, MX Series, and TSeries)—Beginning in Junos OS Release 13.3, nonstop active routing support for BGPaddpath is available on the M Series, MX Series, and T Series. Nonstop active routing

support is enabled for the BGP addpath feature. After the nonstop active routing

switchover, addpath-enabled BGP sessions do not bounce. The secondary Routing

Engine maintains the addpath advertisement state before the nonstop active routing

switchover.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-ldp-database.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-ldp-p2mp.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/interfaces-configuring-multi-chassis-link-aggregation.html

• Interchassis high availability provides stateful redundancy (MS-MPC andMS-MICinterface cards onMXSeries routers)—Starting with Release 13.3, Junos OS supportsstateful high availability (HA) to replicate flow states on an activeMS-MPCorMS-MIC

service card to a standby MS-MPC or MS-MIC service card on a different chassis. This

enables the preservation of the state of the existing flows in case of a planned or

unplanned switchover.

Services to be synchronized statefully include:

• Stateful firewall

• NAT (NAPT44 and APP only)

Both IPv4 and IPv6 sessions are synchronized.

Synchronizationoccurs for long-lived flowsasdefinedbyaconfigurable synchronization

threshold.

[See Inter-Chassis High Availability for MS-MIC andMS-MPC.]

• Support for unified in-service software upgrade onMX Series routers with MPC3andMPC4E (MX240, MX480, andMX960)—Starting in Release 13.3, Junos OSsupports unified in-service software upgrade (ISSU) on MX Series routers with MPC3

and MPC4E. Unified ISSU is a process to upgrade the system software with minimal

disruption of transit traffic and no disruption of the control plane. In this process, the

new system software version must be later than the version of the previous system

software. When unified ISSU completes, the new system software state is identical

to that of the system software when the system upgrade is performed through a cold

boot.

• MXSeriesVirtual Chassis support for inline flowmonitoring (MXSeries routerswithMPCs)—Starting in Junos OS Release 13.3R3, you can configure inline flowmonitoring

for anMXSeries Virtual Chassis. Inline flowmonitoring enables you to activelymonitor

the flow of traffic by means of a router participating in the network.

Inline flowmonitoring for an MX Series Virtual Chassis provides the following support:

• Active sampling and exporting of both IPv4 and IPv6 traffic flows

• Sampling traffic flows in both the ingress and egress directions

• Configuration of flow collection on either IPv4 or IPv6 devices

• Use of the IPFIX flow collection template for traffic sampling (both IPv4 and IPv6

export records)


• Transmit ESMC SSMquality level from synchronous Ethernetmode (MXSeries)—Starting in Junos OS Release 13.3, when an MX Series router is configured insynchronous Ethernet mode, the ESMC SSM quality level can be transmitted. The setchassis synchronizationmax-transmit-quality-level command sets a thresholdquality level for the entire system.

• Ethernet frame padding with VLAN (DPCs andMPCs running onMX Seriesrouters)—Starting in JunosOSRelease 13.3, DPCs andMPCs onMXSeries routers pad



http://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/nat-interchassis-high-availability-msmic-msmpc.html

the Ethernet frame with 68 bytes if the packet is VLAN tagged and the frame length

is less than68bytesandgreater thanor equal to64bytesat theegressof the interface.

• PTP redundancy support for line cards (MX Series andMSeries)—Beginning withJunos OS Release 13.3, line cards on MX Series and M Series routers support slave

redundancy. If multiple slave streams are configured across line cards and the active

slave line card crashes or all of the streams on that line card lose their timing packets,

another slave line card takes over if it has been primed to do so.

• Increased Layer 3 forwarding capabilities forMPCs andMultiservicesDPCs throughFIB localization(MXSeries)—Starting in JunosOSRelease 13.3, forwarding informationbase (FIB) localization characterizes the Packet Forwarding Engines in a router into

two types: FIB-Remote and FIB-Local. FIB-Local Packet Forwarding Engines install all

of the routes from the default route tables into Packet Forwarding Engine forwarding

hardware. FIB-Remote Packet Forwarding Engines create a default (0.0) route that

referencesanexthoporaunilist ofnexthops to indicate theFIB-Local that canperform

full IP table looks-ups for received packets. FIB-Remote Packet Forwarding Engines

forward received packets to the set of FIB-Local Packet Forwarding Engines.

The capacity of MPCs is much higher than that of Multiservices DPCs, so an MPC is

designatedas the localPacketForwardingEngine, andaMultiservicesDPC isdesignated

as the remote Packet Forwarding Engine. The remote Packet Forwarding Engine

forwards all network-bound traffic to the local Packet Forwarding Engine. If multiple

MPCs are designated as local Packet Forwarding Engines, then the Multiservices DPC

load balances the traffic using the unilist of next hops as the default route.

• Support for centralized clocking (MX2020)—Before Junos OS Release 13.3, theMX2020 supported SyncE (Synchronous Ethernet) in distributedmode, where the

clock module on a line card would lock to the SyncE source and distribute frequency

references to the entire chassis. Starting in Junos OS Release 13.3, the MX2020 uses

the centralized Stratum 3 clock module on the control board to lock onto SyncE and

distribute the frequency to the entire chassis. Supported features include:

• Clock monitoring, filtering, and holdover

• Hitless transition from a distributed to centralized clocking mode

• Distribution of the selected chassis clock source to downstream network elements

through supported line interfaces

You can view the centralized clock module information with the show chassis

synchronization clock-module command.

NOTE: PrecisionTimeProtocol/IEEE1588continuetooperate indistributedmode.

• Enhancements to commit check processing (M Series andMX Series)—Starting inJunos OS Release 13.3, the processing performance when you issue the commit check

command has been optimized for the following static and dynamic interface types:

• Logical demultiplexing (demux) interfaces (demux0)

• PPPoE logical interfaces (pp0)



• Inline services interfaces (si)

The improved performance for commit check enables the overall commit operation to

complete fasterwhennewdemux0,pp0, or si interfacesareadded to theconfiguration.

• Support for ATM virtual connectionmultiplexing and LLC encapsulation (MXSeries)—Starting in Junos OS Release 13.3, ATM virtual connection (VC) multiplexing

and logical link control (LLC) encapsulation are supported on the Channelized

OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP. ATM virtual connection

multiplexing and LLC are the twomethods for identifying the protocol carried in ATM

AdaptationLayer5 (AAL5) frames.Themethodsaredefined inRFC2684,Multiprotocol

Encapsulation over ATM Adaptation Layer 5.

In theATMvirtual connectionmultiplexingmethod, eachATMvirtual connectioncarries

protocol dataunits (PDUs)of exactly oneprotocol type.Whenmultipleprotocols need

to be transported, there is a separate virtual connection for each protocol.

TheLLCencapsulationmethodenablesmultiplexingofmultipleprotocolsoverasingle

ATM virtual connection. The protocol type of each PDU is identified by a prefixed IEEE

802.2 LLC header.

[See ATM Support on Circuit Emulation PICs Overview.]

• Support for MPLS-signaled LSPs to use GRE tunnels (MXSeries)—Starting in JunosOS Release 13.3, MPLS label-switched paths (LSPs) can use generic routing

encapsulation(GRE) tunnels to traverse routingareas, autonomoussystems,and ISPs.

Bridging MPLS LSPs over an intervening IP domain is possible without disrupting the

outlying MPLS domain. This feature is supported on the Channelized OC3/STM1

(Multi-Rate) Circuit Emulation MIC with SFP and is defined in the RFC 4023,

Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE).

[See Configuring MPLS-Signaled LSPs to Use GRE Tunnels.]

• Support for SCBE2 (MX240, MX480, andMX960)—Starting in Junos OS Release13.3, the Enhanced SCB—SCBE2—supports the following features:

• Increased fabric bandwidth per slot

• Improved external clock redundancy

• Dynamic multicast replication only

• GRES

The following scenarios are to be noted when you are using an MX Series router with

an SCBE2:

• Youmust configure the set chassis network-services (enhanced-ip |

enhanced-ethernet) configuration command and reboot the router to bring up the

FPCs on the router. However, after the router reboots, the MS DPC, the MX FPC, and

the ADPC are powered off.

• All the FPCs and DPCs in the router are powered off when you reboot the router

without configuring either the enhanced-ip option or the enhanced-ethernet option

at the [edit chassis network-services] hierarchy level.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-atm-support-on-circuit-emulation-pics-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/mpls-configuring-mpls-signaled-lsps-to-use-gre-tunnels.html

• Youmust reboot the router when you configure or delete the enhanced-ip option or

the enhanced-ethernet option at the [edit chassis network-services] hierarchy level.

[See Centralized Clocking Overview and Network Services Mode Overview.]

• Support for GPS external clock interface on the SCBE (MX240, MX480, andMX960)—Starting with Junos OS Release 13.3, you can configure the EnhancedSCB—SCBE—external clock interface to a GPS timing source, which enables you to

select a GPS external source as the chassis clock source. You can also configure the

external clock interface tooutput either the selectedchassis clock sourceor a recovered

line clock source with GPS timing signals of 1 MHz, 5 MHz, or 10 MHz with 1 pulse per

second (PPS).

[See Centralized Clocking Overview and Understanding Clock Synchronization onMX

Series Routers.]

• Support for mixed-ratemode (T4000 and TXMatrix Plus with 3D SIBs)—Startingwith Junos OS Release 13.3, dual-rate mode or mixed-rate mode for PF-24XGE-SFPP

allows you to configure a mix of port speeds of 1 Gigabit and 10 Gigabit. However, on

PF-12XGE-SFPP, note that youcanconfigureport speedsof either 1Gigabit or 10Gigabit

when the PIC is in line rate mode.

You can enable mixed-rate-mode and set port speeds with themixed-rate-mode

statement and the speed 1G |10G statement, respectively, at the [edit chassis fpc x pic

y] hierarchy level. You can disable themixed-ratemode by using the delete chassis fpc

x pic ymixed-rate-mode statement.

[See Configuring Mixed-Rate Mode Operation.]

• ExtendedMPC support for per-unit schedulers (MX Series)—Starting in Junos OSRelease 13.3,you can configure per-unit schedulers on the non-queuing 16x10GEMPC,

MPC3E, andMPC4E,meaning you can include the per-unit-scheduler statement at the

[edit interfaces interface name] hierarchy level. When per-unit schedulers are enabled,

you can define dedicated schedulers for the logical interfaces.

Enablingper-unit schedulerson the 16x10GEMPC,MPC3E, andMPC4Eaddsadditional

output to the show interfaces interface name [detail | extensive] command. This

additional output lists themaximumresourcesavailableand thenumberof configured

resources for schedulers.

[See Scheduler Maps and Shaping Rate to DLCIs and VLANs.]

• Provider edge link protection for BGP labeled unicast paths (M Series, MX Series,and T Series)—Starting in Junos OS Release 13.3, a precomputed protection path canbe configured in a Layer 3 VPN such that if a BGP labeled-unicast path between an

edge router in oneASand an edge router in another AS goes down, the protection path

(also known as the backup path) between alternate edge routers in the two ASs can

be used. This is useful in carrier-of-carriers deployments, where a carrier can have

multiple labeled-unicast paths to another carrier. In this case, the protection path

avoids disruption of service if one of the labeled-unicast paths goes down.

[See Understanding Provider Edge Link Protection for BGP Labeled Unicast Paths.]

• Redundant logical tunnels (MXSeries)—Beginningwith JunosOSRelease 13.3, whenyouconnect twodevices through logical tunnels, you cancreateandconfiguremultiple



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/chassis_centralized_clocking_overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/network-services-mode-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/chassis_centralized_clocking_overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/chassis-external-clock-synchronization-interface-understanding-mx.html


http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/configure-mixed-mode-operation-10ge-pic.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/cos-applying-scheduler-maps-and-shaping-rate-to-dlcis-and-vlans.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/labeled-unicast-provider-edge-link-protection-overview.html

physical logical tunnels and add them to a virtual redundant logical tunnel to provide

redundancy.

• License support to activate ports (MX104)—Starting with Junos OS Release 13.3license support has been extended for activating the ports on MX104 3D Universal

Edge Routers. MX104 routers have four built-in ports. By default, in the absence of any

valid licenses, all four built-in ports are deactivated. The upgrade license model with

the feature IDs is described in Table 1 on page 34.

Table 1: Port LicenseModel for theMX104

FunctionalityFeature NameFeature ID

Ability to activate the first two built-in ports (xe-2/0/0 andxe-2/0/1)

MX104 2X10G Port Activate (0 and 1)F1

Ability to activate the next two built-in ports (xe-2/0/2 andxe-2/0/3)

MX104 2X10G Port Activate (2 and 3)F2

Both features are also provided in a single license key for ease of use. MX104 routers

do not support the graceful license expiry policy.

• Enhanced load-balancing for MIC andMPC interfaces (MX Series)—Starting with

Junos OS Release 13.3, the following load-balancing solutions are supported on

aggregate Ethernet bundles to correct genuine traffic imbalance among themember

links:

• Adaptive—Uses real-time feedbackandcontrolmechanismtomonitor andmanage

traffic imbalances.

• Per-packet random spray — Randomly sprays the packets to the aggregate next

hops to ensure that the next hops are equally loaded, resulting in packet reordering.

TheaggregatedEthernet load-balancing solutionsaremutually exclusive. Toconfigure,

use the adaptive or per-packet statement at the [edit interfaces aex

aggregated-ether-options load-balance] hierarchy level.

[See Example: Configuring Aggregated Ethernet Load Balancing.]

• Support for configuring interface alias names—Starting in JunosOSRelease 13.3, youcan configure a textual description of a logical unit on a physical interface to be the

alias of an interface name. Interface aliasing is supported only at the unit level. If you

configure an alias name, the alias name is displayed instead of the interface name in

the output of all show, show interfaces, and other operational mode commands.

Configuring an alias for a logical unit of an interface has no effect on how the interface

on the router or switch operates. To specify an interface alias, you can use the alias

statement at the [edit interfaces interface-name unit logical-unit-number] and [edit

logical-systems logical-system-name interfaces interface-nameunit logical-unit-number]

hierarchy levels.

[See Interface Alias NameOverview.]

• The request support informationcommand(MXSeries)—Starting in JunosOSRelease13.3, when you enter the request support information command with or without the



http://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/aggregated-ethernet-load-balanicng.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-alias-name-overview.html

brief statement, the output includes the showsystemcommit commandoutput,which

displays the commit history and pending commits.

• Pseudowire logical interfacedeviceMACaddressconfiguration(MXSeries)—Startingin Junos OS Release 13.3, you can configure a MAC address for a pseudowire logical

interface device that is used for subscriber interfaces over point-to-point MPLS

pseudowires. This feature enables you to specify the MAC address of your choice in

situations in which network constraints require the use of an explicit MAC address.

[See Configuring a Pseudowire Subscriber Logical Interface Device.]

• Support for synchronizing the CB of anMX2020 router with external BITS timingsources (MX2020)—Starting in Junos OS Release 13.3, this feature providesbuilding-integrated timing supply (BITS) input and output support to the two external

clock interfaces (ECI) on the Control Board. You can configure the ECIs for both input

and output BITS. In the absence of any configuration, the ECI is inactive.

You can configure the BITS ECI by using the synchronization statement at the [edit

chassis] hierarchy level. You can view the BITS ECI information by using the show

chassis synchronization extensive command.

[See Understanding Clock Synchronization onMX Series Routers.]

• Distribution of Ethernet connectivity fault management sessions (MXSeries)—Starting with Junos OS Release 13.3, connectivity fault management (CFM)sessions operate in distributedmode and can be processed on the Flexible PIC

Concentrator (FPC) on aggregated Ethernet interfaces. As a result, graceful Routing

Engine switchover (GRES) is supported on aggregated Ethernet interfaces. In releases

before Junos OS Release 13.3, CFM sessions operate in centralizedmode and are

processed on the Routing Engine. However, CFM sessions are not supported on

aggregated Ethernet interfaces if the interfaces that form the aggregated Ethernet

bundle are in mixedmode.

CFM sessions are distributed by default. To disable the distribution of CFM sessions

andtooperate incentralizedmode, include theppmno-delegate-processingstatement

at the [edit routing-options ppm] hierarchy level. However, all CFM sessions should

operate in either only distributed or only centralizedmode. Amixed operation of

distributed and centralizedmodes for CFM sessions is not supported.

[See IEEE 802.1ag OAM Connectivity Fault Management Overview.]

• Redundant logical tunnels (MXSeries)—Beginningwith JunosOSRelease 13.3, whenyouconnect twodevices through logical tunnels, you cancreateandconfiguremultiple

physical logical tunnels and add them to a virtual redundant logical tunnel to provide

redundancy.

[See Example: Configuring Redundant Logical Tunnels.]

• Source class accounting (T4000)—Starting with Junos OS Release 13.3R2, sourceclass usage (SCU) accounting is performed at ingress on a T4000 Type 5 FPC.

• SFPP-10G-CT50-ZR (MX Series)—Beginning in Junos OS Release 13.3R3, theSPFF-10G-CT50-ZR tunable transceiver provides a duplex LC connector and supports

the 10GBASE-Z optical interface specification andmonitoring. The transceiver is not

specified as part of the 10-Gigabit Ethernet standard and is instead built according to



http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/pseudowire-interfaces-configuring.html


http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-ieee-802-1ag-oam-connectivity-fault-management-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/redundant-logical-tunnel.html

Juniper Networks specifications. OnlyWAN-PHY and LAN-PHYmodes are supported.

To configure the wavelength on the transceiver, use thewavelength statement at the

[edit interfaces interface-name optics-options] hierarchy level. The following interface

module supports the SPFF-10G-CT50-ZR transceiver:

MX Series:

• 16-port 10-GigabitEthernetMPC(modelnumber:MPC-3D-16XGE-SFPP)—Supported

in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1, and later.



[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications andwavelength.]

• PTP path tracemechanism onMX Series—Starting with Junos OS Release 13.3R4,you can use a path trace mechanism to detect PTP loops in a PTP ring topology over

an IPv4 network. A path trace is the route that aPTPannouncemessage takes through

the network trail of boundary clocks and is tracked through the path trace TLV in the

announcemessage. The path trace sequence contains the clock ID of each boundary

clock that an announcemessage traverses. To view the path trace, use the show ptp

path-trace detail operational mode command.

• Software feature support (MX104)—Starting in Junos OS Release 13.3 support isextended for the following software features on theMX1043DUniversal EdgeRouters:

• IP features—IPv6 Provider Edge (6PE), Access Node Control Protocol (ANCP), DHCP

snooping, DHCP Option-82, Multicast Listener Discovery (MLD), and Domain Name

System (DNS).

• MPLS features—MPLS Transport Profile (MPLS-TP), ATM Single Cell Relay over

MPLS (CRoMPLS) VCMode, Generalized MPLS (GMPLS), and VPNv6.

• Multicast features—Distance Vector Multicast Routing Protocol (DVMRP), Multicast

Listener Discovery (MLD), Multicast Listener Discovery (MLD) Snooping, draft

rosen-multicast VPNs, Multicast version 6, and DHCPv6.

• Layer 2 features—802.1ag threshold negotiation, 802.1X, and Media Access Control

Security (MACsec).

• Resiliency features—Lawful intercept, Inline J-Flow, dynamic ARP inspection (DAI),

reception of dying-gasp protocol data units (PDU), DHCP snooping for port security,

and nonstop active routing (NSR).

[See Protocols and Applications Supported by MX104 Routers.]




http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/configuration-statement/wavelength-edit-interfaces.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mx104-features.html

IPv6

• New forwarding-class-accountingstatement(MXSeries)—Starting in JunosOSRelease13.3R3, new forwardingclassaccounting statistics canbeenabledat the [edit interfaces

interface-name] and [edit interfaces interface-nameunit interface-unit-number] hierarchy

levels. These statistics replace the need to use firewall filters for gathering accounting

statistics. Statistics can be gathered in ingress, egress, or both directions. Statistics

are displayed for IPv4, IPv6, MPLS, Layer 2, and Other families.

NOTE: If you implement this feature in Release 13.3R3, contact JTAC priorto upgrading to Release 14.1R1 or later.

Layer 2 Features

• Computation of the Layer 2 overhead attribute in interface statistics (TSeries)—Starting in Junos OS Release 13.3, on T Series routers, you can configure anattribute at the PIC level to include the Layer 2 overhead (header and trailer bytes) in

the physical interface and logical interface statistics for both ingress and egress

directions. Both the transit and total statistical information includes the Layer 2

overhead in theoutputof theshowinterfaces interface-namecommandforeachphysical

or logical interface on that PIC.

The ifInOctets and ifOutOctets MIB objects display statistics that include Layer 2

overhead bytes.

MPLS

• Multisegment pseudowire for FEC 129 (M Series, MX Series, and T Series)—JunosOS Release 13.3 and later releases provide support for establishing a dynamic

multisegmentpseudowire (MS-PW)withFEC129 inanMPLSpacket-switchednetwork

(PSN). The stitching provider edge (S-PE) devices in anMS-PWare automatically and

dynamically discovered by BGP, and the pseudowire is signaled by LDP using FEC 129.

This arrangement requires minimum provisioning on the S-PEs, thereby reducing the

configuration burden that is associatedwith statically configured Layer 2 circuits while

still using LDP as the underlying signaling protocol.

TheMS-PW feature also provides operation, administration, andmanagement (OAM)

capabilities, such as ping, traceroute, and Bidirectional Forwarding Detection (BFD),

from the terminating PE (T-PE) devices of an MS-PW.

[See Example: Configuring a Multisegment Pseudowire.]

• Control word for BGP VPLS (M320 andMX Series)—For hash calculation, transitrouters must determine the payload. While parsing an MPLS encapsulated packet for

hashing, a transit router can incorrectly calculate an Ethernet payload as an IPv4 or

IPv6 payload if the first nibble of the DAMAC is 0x4 or 0x6, respectively. This false

positive can cause out-of-order packet delivery over a pseudowire. Starting in Junos

OS Release 13.3R3, this issue can be avoided by configuring a BGP VPLS PE router to



http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/example-configuring-multisegment-pseudowire.html

request that other BGP VPLS PE routers insert a control word between the label stack

and the MPLS payload.

Multicast

• IGMP and PIM snooping support (MPC3E andMPC4E onMX240, MX480, andMX960)—Starting with Junos OS Release 13.3, IGMP snooping and PIM snooping are

supportedon theMX240,MX480,andMX960withModularPortConcentrators (MPC)

MPC3E and MPC4E.


• BFD session enhancements (MX Series routers with MPCs or MICs)—Starting inJunosOSRelease 13.3, the followingBFDsessionenhancementshavebeen introduced:

• enhanced-ip option—For BFD over aggregated Ethernet (ae) interfaces, configuringtheenhanced-ipoptionat the [editchassisnetwork-services]hierarchy level increases

the number of BFD sessions. When you activate or deactivate this option, the router

must be rebooted.

• Inlinemode—This enables the router to transmit and receive BFD packets from the

FPChardware. Currently, for BFDover aggregated Ethernet (ae) interfaces, the inline

mode is supported only on MX Series routers with MPCs/MICs that have configured

theenhanced-ipoption. ForBFDoverGigabit Ethernet interfacesandVLAN interfaces,

the inlinemode is supportedbydefault onall theMXSeries routerswithMPCs/MICs.

• ISSUtimernegotiation—During unified ISSU, the timer for BFDsessions is increasedfrom the configured value to 60 seconds.

• Support for BFD over child links of AE or LAG bundle (cross-functional PacketForwarding Engine/kernel/rpd) (M Series, MX Series, and T Series)—Beginning inJunos OS Release 13.3, BFD over child links of an AE or LAG bundle is supported. This

feature provides a Layer 3 BFD liveness detection mechanism for child links of the

Ethernet LAG interface. You can enable BFD to run on individual member links of the

LAG tomonitor the Layer 3 or Layer 2 forwarding capabilities of individual member

links. Thesemicro BFD sessions are independent of each other despite having a single

client that manages the LAG interface. To enable failure detection for aggregated

Ethernet interfaces, include thebfd-liveness-detection statementat the [edit interfaces

aex aggregated-ether-options bfd-liveness-detection] hierarchy level.

[See Understanding Independent Micro BFD Sessions for LAG.]



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/bfd-for-lag-overview.html

OpenFlow

• Support for OpenFlow v1.0 (MX80, MX240, MX480, andMX960)—Starting withJunos OS Release 13.3, the MX80, MX240, MX480, and MX960 routers support

OpenFlow v1.0. OpenFlow enables you to control traffic in an existing network using

a remote controller by adding, deleting, andmodifying flows on a switch. You can

configure oneOpenFlow virtual switch and one activeOpenFlow controller at the [edit

protocols openflow] hierarchy level on each device running Junos OS that supports

OpenFlow. On MX Series routers that support OpenFlow, you can also direct traffic

fromOpenFlow networks over MPLS networks by using logical tunnel interfaces and

MPLS LSP tunnel cross-connects.

[SeeOpenFlow Feature Guide.]


• VirtualRouteReflector(VRR)—Starting in JunosOSRelease 13.3R3, youcan implementroute reflector capabilityusingageneralpurposevirtualmachineona64-bit Intel-based

blade server or appliance. Benefits of the VRR are:

• Improved scalability (depending on the server core hardware use

• Scalability of the BGP network with lower cost using VRR at multiple locations in

the network

• Fast andmore flexible deployment using Intel servers rather than router hardware

• Space savings through elimination of router hardware

Port Security

• Static ARPwithmulticast MAC address for an IRB interface—Starting in Junos OSRelease 13.3, you can configure a static ARP entry with a multicast MAC address for

an IRB interface that acts as the gateway to the network load balancing (NLB) servers.

Earlier, the NLB servers dropped packets with a unicast IP address and amulticast

MACaddress. JunosOS 13.3 supports the configurationof a staticARPwith amulticast

MAC address.

To configure a static ARP entry with a multicast MAC address for an IRB interface,

configure the ARP entry at the [edit interfaces irb unit logical-unit-number family inet

address address] hierarchy level.

irb {unit logical-unit-number{family inet {address address{arp addressmulticast-macmac-add;

}}

}}



http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/junos-sdn/junos-sdn-openflow.html

Routing Policy and Firewall Filters

• Using a firewall filter to prevent or allow datagram fragmentation (MXSeries)—Starting in Junos OS Release 13.3, you can define a firewall filter term to

prevent or allow datagram fragmentation by setting or clearing the Don’t Fragment

flag in the IPv4 header of packets that are matched by the filter. Specify the desired

action at the [edit firewall family inet filter filter-name term term-name then action]

hierarchy level.

• To prevent fragmentation of the IP datagram, include the dont-fragment set action

in a term to set the dont-fragment bit to one.

• To allow fragmentation of the IP datagram, include the dont-fragment clear action

in a term to clear the dont-fragment bit to zero.

[See Configuring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentation and

Firewall Filter Nonterminating Actions.]

• Newfirewall filtergre-keyfieldmatchcondition—Starting in JunosOSRelease 13.3R3,there is a new gre-key match condition at the [edit firewall family inet filter filter-name

term term-name from] hierarchy level. The gre-key match condition allows a user to

match against the gre key field which is an optional field in gre encapsulated packets.

The key can bematched as a single key value and or a range of key values.

• Support for consistent load balancing for ECMP groups (MX Series routers withMPCs)—Starting in Junos OS Release 13.3, effective in Junos OS Release 13.3R3, onMX Series 3D Universal Edge Routers with modular port concentrators (MPCs) only,

you can prevent the reordering of flows to active paths in an ECMP group when one or

more paths fail. Only flows that are inactive are redirected. This feature applies only

to Layer 3 adjacencies learned through external BGP connections. It overrides the

default behavior of disrupting all existing, including active, TCP connections when an

active path fails. Include the consistent-hash statement at the [edit policy-options

policy-statement policy-statement-name then load-balance] hierarchy level. Youmust

also configure a global per-packet load-balancing policy.

[See Actions in Routing Policy Terms. ]

• New fast-lookup-filter statementonMX240,MX480,MX960,MX2010andMX2020routers with MPC5E, MPC5EQ andMPC6EMPCs and compatible MICs—Starting inJunos OS Release 13.3R3, the fast-lookup-filter option is available at the [edit firewall

family (inet | inet6) filter filter-name] hierarchy level. This allows for hardware assist

from compatible MPCs in the firewall filter lookup. There are 4096 hardware filters

available for thispurpose, eachofwhichcansupport up to255 terms.Within the firewall

filters and their terms, ranges, prefix lists, and the except keyword are all supported.

Only the inet and inet6 protocol families are supported.

• Newaction settings for firewall filter termwhen next-interface is down—In previousversions of JunosOS, if the then clause of a firewall filter termwas set to next-interface

and that next interface went down, there would be traffic loss because the default

action is to drop the packet.

Starting in Junos OS Release 13.3R3, the actions accept and next term are available at

the [edit firewall family inet filter filter-name term term-name then next-interface



http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/firewall-filter-dont-fragment-set-clear.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/firewall-filter-actions-nonterminating.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-actions-in-routing-policy-terms.html

interface-name] hierarchy level. There is no new configuration option available if the

firewall filter term action is set to next-ip, meaning that if the next-ip is down, traffic is

still dropped.

The action configured at this level only becomes active if the next-interface is down

and the ARP on the interface is cleared. If not configured, the default action is to drop

the packet.

Routing Protocols

• Support forBMPversion3—Starting in JunosOSRelease 13.3, BGPmonitoringprotocol(BMP)version3 is supported.BMPallowsa remotedevice (theBMPstation) tomonitor

BGP as it is running on a router or group of routers. BMP version 3 includes substantial

additional functionality versusversion 1. TheBMPversion3configuration is incompatible

with the old version. If you are running BMP version 1 on your Juniper Networks devices,

be sure to update your BMP configurationwhen you upgrade to JunosOSRelease 13.3.

[See Configuring BGPMonitoring Protocol Version 3.]

• Support for consistent load balancing for ECMP groups (MX Series routers withMPCs)—Effective in JunosOSRelease 13.3R3, onMXSeries 3DUniversal EdgeRouterswithmodular port concentrators (MPCs) only, you can prevent the reordering of flows

to active paths in an ECMP group when one or more paths fail. Only flows that are

inactive are redirected. This feature applies only to Layer 3 adjacencies learned through

external BGP connections. It overrides the default behavior of disrupting all existing,

includingactive, TCPconnectionswhenanactivepath fails. Include the consistent-hash

statement at the [edit policy-options policy-statement policy-statement-name then

load-balance] hierarchy level. Youmust also configure a global per-packet

load-balancing policy.

[See Actions in Routing Policy Terms. ]

• Recursive DNS server ICMPv6 router advertisement option support (M Series, MXSeries, and T Series)—Beginning with Junos OS Release 13.3R4, you can configure amaximum of three recursive DNS server addresses and their respective lifetimes via

static configuration at interface level for IPv6 hosts. Previously, rpd supported only

link-local address information, prefix information, and the link MTU. The router

advertisement-based DNS configuration is useful in networks where an IPv6 host’s

address is auto-configured through an IPv6 stateless address and where there is no

DHCPv6 infrastructure available.

Toconfigure the recursiveDNSserveraddress, include thedns-server-addressstatement

at the [edit protocols router-advertisement interface interface-name] hierarchy level.

[See Example: Configuring Recursive DNS Address.]



http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/bgp-monitoring-protocol-v3.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/policy-configuring-actions-in-routing-policy-terms.html

http://www.juniper.net/techpubs/en_US/junos14.1/topics/topic-map/recursive-dns-server.html.

Services Applications

• EnablingLayer2ProtocolTunneling(L2PT)support forVLANSpanningTreeProtocol(VSTP) and per-VSTP (MX Series routers with MPC/MICs)—Starting in Junos OS

Release 13.3, this feature enables L2PT support for VSTP/PVSTP.

[See layer2-control.]

You can also enable rewriting of the MAC address for an interface using the

enable-all-ifl option.

[Seemac-rewrite.]

• Chainedcompositenexthops(MXSeriesandTSeries)—Starting in JunosOSRelease13.3, the support of chained composite next hops for directly connected provider edge

(PE) routers varies fromoneplatform toanother.OnMXSeries routers containingboth

DPC and MPC FPCs, chained composite next hops are disabled by default. To enable

chained composite next hops on the MX240, MX480, and MX960, the chassis must

be configured to use the enhanced-ip option in network services mode. On T4000

routers containingMPCandFPCs, chainedcompositenexthopsaredisabledbydefault.

To enable chained composite next hops on a T4000 router, the chassis must be

configured to use the enhanced-mode option in network services mode.

• Data plane inline support added for 6rd and 6to4 tunnels connecting IPv6 clientsto IPv4 networks onMX Series routers with MPC line cards—Starting with Release13.3R3, Junos OS supports inline 6rd and 6to4 on Modular Port Concentrator (MPC)

line cards with Trio chipsets, saving customers the cost of using MS-DPCs for the

required tunneling, encapsulation, and decapsulation processes. Anycast is supported

for 6to4 (next-hop service interfaces only). Hairpinning is also supported for traffic

between 6rd domains.

There are no CLI changes for 6rd and 6to4 configurations. To implement the inline

functionality, configure service interfaces on theMPC card as inline services interfaces

(si- ) rather than as MultiServices (ms-) interfaces.

Two new operational commands have been added: show services inline softwire

statistics and clear services inline softwire statistics

• IPsec invalid SPI notification (MX Series, T Series)—Starting in Junos OS release13.3R4, you can enable automatic recovery when peers in a security association (SA)

become unsynchronized. When peers become unsynchronized, this can cause the

transmission of packets with invalid security parameter index (SPI) values and the

dropping of those packets by the receiving peer. You can enable automatic recovery

by using the new respond-bad-spi max-responses configuration statement, which

appears under the hierarchy level [edit services ipsec-vpn ike policy]. This statement

results in a resynchronization of the SAs.

The max-responses value has a default of 5 and a range of 1 through 30.

• IPsec InvalidSPINotification(MXSeriesandT-Series)—Starting in JunosOSRelease13.3R4, you can enable automatic recovery when peers in a security association (SA)

become unsynchronized. When peers become unsynchronized, this can cause the

transmission of packets with invalid security parameter index (SPI) values and the

dropping of those packets by the receiving peer. You can enable automatic recovery



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/layer2-control-edit-protocols.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/mac-rewrite-edit-protocols-layer2-control.html

by using the new respond-bad-spi max-responses configuration statement, which

appears under the [edit services ipsec-vpn ike policy] hierarchy level. This statement

results in a resynchronization of the SAs.

The max-responses value has a default of 5 and a range of 1 through 30.


• Support for autoinstallation of satellite devices in a JNU group—In a Junos NodeUnifier (JNU) topology that contains anMX Series router as a controller that manages

satellite devices, such as EX Series Ethernet Switches, QFX Series devices, and ACX

Series Universal Access Routers, the autoinstallation functionality is supported for the

satellite devices. Starting in Junos OS Release 13.3, JNU has an autoinstallation

mechanism that enables a satellite device to configure itself out-of-the-box with no

manual intervention, using the configuration available either on the network or locally

through a removable media, or using a combination of both. This autoinstallation

method is also called the zero-touch facility.

A JNU factory default file, jnu-factory.conf, is present in the /etc/config/ directory and

contains the configuration to perform autoinstallation on satellite devices. The

zero-touch configuration can be disabled by including the delete-after-commit

statement at the [edit system autoinstallation] hierarchy level and committing the

configuration.

[See Autoinstallation of Satellite Devices in a Junos Node Unifier Group and Configuring

Autoinstallation on JNU Satellite Devices.]

Subscriber Management and Services

• Pseudowire subscriber logical interfacesMPCsupport—Starting in JunosOSRelease13.3, pseudowire subscriber logical interfaces are supported on MPCs with Ethernet

MICs only.

• Service packet counting (MX Series)—Starting in Junos OS Release 13.3, you canconfigure the counters that subscriber management uses when capturing volume

statistics for subscribers on a per-service session basis.

• Inline countersare capturedwhen theeventoccurs, anddonot includeanyadditional

packet processing events that occur after the event.

• Deferred counters are not incremented until the packet is queued for transmission,

and therefore include theentirepacketprocessing.Deferredcountersprovideamore

accurate packet count than inline counters, and are more useful for subscriber

accounting and billing.

NOTE: Fast update filters do not support deferred counters.

[See Configuring Service Packet Counting.]

• RADIUS logical line identifier (MX Series)—Starting in Junos OS Release 13.3, serviceproviders can use a virtual port feature, known as the logical line ID (LLID), tomaintain

a reliable and up-to-date customer database for those subscribers whomove from



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/autoinstallation-jnu-satellites-overviw.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/autoinstallation-jnu-satellites-configuring.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/autoinstallation-jnu-satellites-configuring.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/firewall-filter-service-accounting.html

one physical line to another. The LLID, which is based on the subscriber's user name

and circuit ID, is mapped to the subscriber's physical line. When the subscriber moves

to a different physical line, the service provider database is updated to map the LLID

to the new physical line. Subscriber management supports the LLID feature for PPP

subscribers over PPPoE, PPPoA, and LAC.

[See RADIUS Logical Line Identifier (LLID) Overview.]

• Configurable timers for DHCPv6 address-assignment pools (MX Series)—Startingin Junos OS Release 13.3, subscriber management on MX Series routers supports

configurable timers for address-assignment pools that are used by a DHCPv6 local

server. In addition to the previously supportedmaximum-lease-time timer, you can

configure the valid-lifetime and preferred-lifetime timers to manage address leases

provided by address-assignment pools. You can also configure the renew (T1) and

rebind(T2) times thatsubscribermanagementuses toextendthe lifetimesofaddresses

obtained from an address-assignment pool.

[See DHCPv6 Lease Timers.]

• DHCP statements and options (MX Series)—Starting in Junos OS Release 13.3, youcan use the following statements and options for DHCP subscriber management

support:

• incoming-interface—Newoption thatprovides secondary identificationmatchcriteria

for the DHCP auto logout feature when there are duplicate clients.

• delay-authentication—New statement that conserves managed resources on the

router by delaying subscriber authentication until the DHCP request processing

phase.

• server-response-time—New statement that configures the timeframe during which

the router monitors DHCP server responsiveness. The router generates a system log

message when the DHCP server does not respond to relayed packets during the

specified time.

• option hex-string—New option that enables the use of the hex-string option type for

user-defined DHCP attribute options that are added to client packets.

• duplicate-clients-in-subnet—New statement that configures how the router

distinguishes between duplicate clients in the same subnet. This replaces the

duplicate-clients-on-interface statement, which is now obsolete.

[See client-discover-match, delay-authentication, server-response-time, option, and

duplicate-clients-in-subnet.]

• Support for agent circuit identifier filtering in PPPoE subscriber session lockout(M120, M320, andMX Series)—Starting in Junos OS Release 13.3, extend PPPoEsubscriber session lockout has been extended to support identification and filtering of

PPPoEsubscriber sessionsbyeither theagent circuit identifier (ACI) valueor theunique

MAC source address on static or dynamic VLAN and static or dynamic VLAN demux

underlying interfaces. In earlier Junos OS releases, PPPoE subscriber session lockout

identified and filtered subscriber sessions only by their unique MAC source address.

ACI-based or MAC-based PPPoE subscriber session lockout prevents a failed or

short-lived PPPoE subscriber session from reconnecting to the router for a default or



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/subscriber-management-llid-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/dhcpv6-lease-timers.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/client-discover-match-edit-system-services.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/delay-authentication-edit-forwarding-options.html

www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/server-response-time-edit-forwarding-options.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/option-edit-access.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/duplicate-clients-in-subnet-edit-forwarding-options.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/duplicate-clients-in-subnet-edit-forwarding-options.html

configurable time period. ACI-based PPPoE subscriber session lockout is useful for

configurations such as PPPoE interworking in which MAC source addresses are not

unique on the PPPoE underlying interface.

ToconfigureACI-basedPPPoEsubscriber session lockout, use theshort-cycle-protection

statement with the filter aci option. To clear an ACI-based lockout condition, issue the

clear pppoe lockout command with the aci option.

[See PPPoE Subscriber Session Lockout Overview.]

• Subscriber management and services feature parity (MX80)—Starting in Junos OSRelease 13.3, the MX80 supports all subscriber management and services features

that are supported by the MX240, MX480, and MX960 routers. Previously, the MX80

router matched feature support for these routers as of Junos OS Release 11.4.

[See Protocols and Applications Supported by MX5, MX10, MX40, andMX80 Routers.]

• Subscriber management and services feature and scaling parity (MX2010 andMX2020)—Starting in Junos OS Release 13.3, the MX2010 and the MX2020 supportall subscriber management and services features that are supported by the MX240,

MX480, and MX960 routers. In addition, the scaling and performance values for the

MX2010 and the MX2020match those of MX960 routers.

[See Protocols and Applications Supported by MX240, MX480, MX960, MX2010, and

MX2020MPCs,ProtocolsandApplicationsSupportedbyMX240,MX480,MX960,MX2010,

andMX2020 EnhancedMPCs (MPCEs), Protocols and Applications Supported by the

MX240, MX480, MX960, MX2010, andMX2020MPC3E, and Protocols and Applications

Supported by the MX240, MX480, MX960, MX2010, andMX2020MPC4Es.]

• Per-subscriber support for multiple instances of the same service with differentparameters (MX Series routers with MPCs or MICs)—Starting In Junos OS Release13.3, a subscriber can havemultiple instances of the same service, provided that each

service instance has a different set of parameters. In earlier Junos OS releases, each

subscriber was limited to only a single instance of each service.

You can configure a specific service instance for a particular subscriber by specifying

a service name and unique service parameters for that instance. Each service instance

is uniquely identified by the combination of its service name and service parameters.

Use the request network-access aaa subscriber delete command to deactivate all

instances of a subscriber service by specifying only the service name, or to deactivate

a specific instance of a service by specifying both the service nameand its parameters.

In earlier Junos OS releases, you deactivated a service by specifying only its service

name, but not its service parameters.

[See Subscriber Services with Multiple Instances Overview.]

• RADIUS accountingmessages for dual-stack subscribers (MX Series)—Starting inJunos OS Release 13.3, when an IPv6 address is assigned using DHCPv6, the RADIUS

interimaccountingmessage includes theassigned IPv6address. If thedelegatedprefix

is provided to the client using DHCPv6-PD, the RADIUS interim accounting message

includes the delegated prefix (IA_PD, such as /56). The

address-change-immediate-updatestatement isnoweffective foranyaddressallocation

changeafteranAcct-Startmessage is issued(for IPv6NCPandDHCPv6).An immediate



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/subscriber-management-pppoe-lockout.html


http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-features.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-features.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpce-mx-series-features.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpce-mx-series-features.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-mpc3e-features.html




http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/subscriber-management-multi-instance-services-oview.html

Interim-Acctmessage is sentuponanysubsequentDHCPv6negotiationandallocation

whennewallocatedaddressesareadded.After IPv6NCPnegotiation,DHCPv6address

allocation and negotiation occurs.

[See RADIUS Accounting Messages for Dual-Stack Subscribers.]

• Support for IPv6 for TACACS+ authentication (MSeries, MX Series, and T Series)—StartingwithRelease 13.3, JunosOSsupports IPv6alongwith theexisting IPv4 support

for user authentication using TACACS+ servers.

• Configurable L2TP receive window size (MX Series)—Starting in Junos OS Release13.3, the new rx-window-size statement at the [edit services l2tp tunnel] hierarchy level

enables you to specify the size of the receive window in the range 4 through 128 on an

L2TP LAC or LNS. The default value is 4. The ReceiveWindow Size AVP (Attribute

Type 10) is not sent in the SCCRQmessage when the default value is configured on a

LAC or in the SCCRPmessage when configured on an LNS.

[See Setting the L2TP ReceiveWindow Size.]

• Clearing ANCP statistics (MX Series)—Starting in Junos OS Release 13.3, you canclear all ANCPstatisticswith the clearancpstatistics command.Youcanclear statistics

for a particular neighbor identified by the neighbor’s IP address with the clear ancp

statistics ip-address ip-address command. You can clear statistics for a particular

neighbor identified by the neighbor’s IP address with the clear ancp statistics

system-namemac-address command.

[See Clearing and Verifying ANCP Statistics.]

• ANCP agent support for nonzero partition IDs (MX Series)—Starting in Junos OSRelease 13.3, the ANCP agent on the router can form adjacencies with multiple logical

partitions on a neighbor when you enable the agent to learn partition IDs during

adjacency negotiation with the neighbor. If the agent receives a SYNmessage from

the neighbor within a configurable period, the agent learns the partition IDs and can

form adjacencies with the partitions. The agent can form an adjacency only with the

neighbor if the SYN is not receivedwithin the period, the partition ID is zero, or learning

is not enabled.

[See Configuring the ANCP Agent to Learn ANCP Partition IDs.]

• Dynamic protocol version detection for ANCP (MX Series)—Starting in Junos OSRelease 13.3, when an ANCP neighbor opens adjacency negotiations, it indicates the

highest version of ANCP that it supports. ANCP neighborsmust be able to identify the

supported versions because ANCP Version 1, defined in RFC 6320, Protocol for Access

Node Control Mechanism in Broadband Networks, is not interoperable with the earlier

version based on GSMPv3.

During negotiation, the receiving neighbor returns the value sent by the other neighbor

if it supports that version, or drops the message if it does not. You can still configure

the router to operate in pre-ietf mode for interoperability with neighbors that support

only GMSPv2.

[See ANCP Topology Discovery and Traffic Reporting Overview.]

• Support forANCPgeneric responsemessagesandresultcodes(MXSeries)—Startingin Junos OS Release 13.3, the ANCP agent supports receipt of generic response



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/subscriber-management-dual-stack-accounting-messages.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/subscriber-management-l2tp-lac-receive-window-size.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/verification/ancp-subscriber-access-statistics-clearing-verifying.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/ancp-partition-id-learning.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/ancp-overview.html

messages. Upon receipt, the router generates a system log, increments the generic

messagecounters,and increments the resultcodecounters.Generic responsemessages

(GRMs) are typically sent instead of specific responsemessageswhen no information

needs to be sent other than a result of success or failure. When themessage reports

a failure, it must include one of eight result codes to indicate the cause. A GRM can

also be sent independent of a request when the failure causes the adjacency to be

shut down.


• Support for sending and receiving the ANCP Status-Info TLV (MX Series)—Startingin Junos OS Release 13.3, the Status-Info TLV supplements the generic response

message result codes and provides information about a warning or error condition.

Although usually included in generic responsemessages, the TLV can also be included

inotherANCPmessage types.TheStatus-InfoTLVmustbe included ingeneric response

messages when the result code indicates a port is down, a port does not exist, a

mandatory TLV is missing, or a TLV is invalid.


• DNS address assignment in DHCPv6 IA_NA and IA_PD environments (MXSeries)—Starting in Junos OS Release 12.3R3 and Release 13.3 (but not in Releases13.1 and 13.2), the DHCPv6 local server returns the DNS server address (DHCPv6

attribute 23) as a global DHCPv6 option, rather than as an IA_NA or IA_PD suboption.

DHCPv6 returns theDNSserveraddress that is specified in the IA_PDor IA_NApools—if

both address pools are requested, DHCPv6 returns the address specified in the IA_PD

pool only, and ignores any DNS address in the IA_NA pool.

In releases earlier than 12.3R3, and in Releases 13.1 and 13.2, DHCPv6 returns the DNS

server address as a suboption inside the respective DHCPv6 IA_NA or IA_PD header.

You can use themulti-address-embedded-option-response statement at the [edit

systemservicesdhcp-local-serverdhcpv6overrides]hierarchy level to revert to theprior

behavior. However, returning the DNS server address as a suboption can create

interoperability issues for some CPE equipment that cannot recognize the suboption

information.

[See DHCPv6 Options in a DHCPv6Multiple Address Environment.]

• Support for filtering trace results by subscribers for AAA, L2TP, and PPP (MXSeries)—Starting in Junos OS Release 13.3, you can filter trace results for someprocesses by subscriber. The reduced set of results simplifies troubleshooting in a

scaled environment. Specify the useruser@domain option at the appropriate hierarchy

level:

• AAA (authd)—[edit system processes general-authentication-service traceoptions

filter]

• L2TP (jl2tpd)—[edit services l2tp traceoptions filter]

• PPP (jpppd)—[edit protocols ppp-service traceoptions filter]

You can filter on the user, the domain, or both. You can use a wildcard (*) at the

beginningor endof each term, as in the following examples: [email protected], tom*,

*tom, *ample.com, tom@ex*, tom*@*example.com.





http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/dhcpv6-dns-server-address.html

You cannot filter results using a wildcard in the middle of the user or domain, as in the

following examples: tom*[email protected], tom125@ex*.com.

Traces that have insufficient information to determine the subscriber username are

automatically excluded from the results.

• Overriding the preferred source address as the source address of NeighborSolicitation/Neighbor Advertisement (NS/NA) on unnumbered interfaces (MXSeries)—By default, if a preferred source address is configured on an unnumberedinterface, thatpreferredaddress is usedas the sourceaddressofNS/NA. If nopreferred

sourceaddress is configured, the routerusesasuitableaddressbasedon thedestination

address scope. Starting in Junos OS Release 13.3, you can configure the router to

override the default configuration of using the preferred source address for NS/NA.

The router ignores thepreferred sourceaddressandusesanappropriateaddressbased

on the destination address scope.

• DHCPv6 local server and relay agent usernameandoption 37 (MXSeries)—Startingin Junos OS Releases 12.3R7, 13.2R4, 13.3R2, the router supports the generation of an

ASCII versionof theauthenticationusername.WhenyouconfigureDHCPv6 local server

or relay agent to concatenate the authentication usernamewith the Agent Remote-ID

option 37, the router uses only the remote-id portion of option 37 and ignores the

enterprise number.

The router no longer supports the enterprise-id and remote-id options for the

relay-agent–remote-id statement.

• Subscribermanagement and services feature and scaling parity (MX104)—Startingin Junos OS Release 13.3R3, the MX104 router supports all subscriber management

and services features that are supported by the MX80 router. In addition, the scaling

and performance values for the MX104 router match those of the MX80 router.

[See Protocols and Applications Supported by MX5, MX10, MX40, andMX80 Routers.]

• DHCPrelayagent forclients indifferentVRFthanDHCPserver (MXSeries)—Startingin JunosOSRelease 13.3R3, subscribermanagementprovides enhanced securitywhen

exchanging DHCPmessages between a DHCP server and DHCP clients that reside in

different virtual routing instances (VRFs). The DHCP cross-VRFmessage exchange

uses the DHCP relay agent to ensure that there is no direct routing between the client

VRF and the DHCP server VRF.

To exchange DHCPmessages between the two VRFs, you configure both the server

side and the client side of the DHCP relay to permit traffic based on the Agent Circuit

ID (DHCP option 82 suboption 1) in DHCPv4 packets and the Relay Agent Interface-ID

(DHCPv6 option 18) in DHCPv6 packets.

• Subscriber management and services feature and scaling parity (MX2010 andMX2020)—Starting in Junos OS Release 13.3, the MX2010 and the MX2020 supportall subscriber management and services features that are supported by the MX240,

MX480, and MX960 routers. In addition, the scaling and performance values for the

MX2010 and the MX2020match those of MX960 routers.




VPNs

• Enhancedmulticast VPNs traceoptions statement (M Series, MX Series, and TSeries)—Starting in JunosOSRelease 13.3, themulticastVPNs traceoptions statementhas been enhanced starting in Junos OS Release 13.3. This statement can now be

configured at the [edit protocolsmpvn] hierarchy level. In addition, the following

traceoption flags have been added: cmcast-join, inter-as-ad, intra-as-ad, leaf-ad,

mdt-safi-ad, source-active, spmsi-ad, tunnel, and umh.

[See Tracing MBGPMVPN Traffic and Operations.]

• Enhanced egress protection in Layer 3 VPNs (M Series, MX Series, and TSeries)—Starting in Junos OS Release 13.3, enhanced point-of-local-repair (PLR)functionality is available, in which the PLR reroutes service traffic during an egress

failure. As part of this enhancement, the PLR router no longer needs to be directly

connected to the protector router. Previously, if the PLR was not directly connected

to the protector router, the loop-free alternate route did not find the backup path to

the protector. A new configuration statement, advertise-mode, enables you to set the

method for the interior gateway protocol (IGP) to advertise egress protection

availability.

[See Configuring Layer 3 VPN Egress Protection with RSVP and LDP.]

• Control word for BGP VPLS (M320 andMX Series)—For hash calculation, transitrouters must determine the payload. While parsing an MPLS encapsulated packet for

hashing, a transit router can incorrectly calculate an Ethernet payload as an IPv4 or

IPv6 payload if the first nibble of the DAMAC is 0x4 or 0x6, respectively. This false

positive can cause out-of-order packet delivery over a pseudowire. Starting in Junos

OS Release 13.3R3, this issue can be avoided by configuring a BGP VPLS PE router to

request that other BGP VPLS PE routers insert a control word between the label stack

and the MPLS payload.

• Loop prevention in VPLS network due toMACmoves (MX Series)—Starting with

Junos OS Release 13.3R3, the base learning interface approach and the statistical

approach can be used to prevent a loop in a VPLS network by disabling the suspect

customer facing interface that is connected to the loop. Some virtual MACs can

genuinely move between different interfaces and such MACs can be configured to

ignore themoves.Thecooloff timeandstatistical approachwait timeareused internally

to find out the looped interface. The interface recovery time can be configured to

auto-enable the interface that gets disabled due to a loop in the network. To configure

these parameters of VPLSMACmoves, include the vpls-mac-move statement at the

[edit protocols l2-learning] hierarchy level. The show vplsmac-move-action instance

instance-name command displays the learning interfaces that are disabled, in a VPLS

instance due to a MACmove. The clear vplsmac-move-action interface ifl-name

command enables an interface disabled due to a MACmove.







http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/troubleshooting/mvpn-traceoptions-configuring.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/l3vpn-service-mirroring-rsvp.html







of Junos OS statements and commands from Junos OS Release 13.3R4 for the M Series,

MX Series, and T Series.

• IPv6 on page 51


• Management on page 53

• MPLS on page 53

• Multicast on page 54


• Routing Policy and Firewall Filters on page 54








IPv6

• Starting with Junos OS Release 11.4R11, interim-logging is supported with NAT64 on

microkernel (MS-DPC) platforms. The configuration statement

pba-interim-logging-interval under the [interfaces services-options] hierarchy level

enables the feature for NAT64.


• Validation of deactivated inline services MLPPP bundle interfaces—Starting withJunos OS Release 13.3, if you attempt to delete or deactivate a static inline service (si)

MLPPPbundle interface that is still referencedby amember link interface,which could

be PPPoE (pp0) or si logical interfaces, and commit the configuration, the commit

operation fails. Youmust reactivate such MLPPP bundle interface before committing

the settings. Alternatively, youmust ensure that member links do not refer a static

MLPPPbundlebefore youdeleteordeactivate thebundle. Thismethodofdeactivation

and reactivation of an MLPPP bundle is not applicable for interfaces other than si-

interfaces, such as link services IQ (lsq-) and virtual LSQ redundancy (rlsq-) interfaces.

[See Understanding MLPPP Bundles and Link Fragmentation and Interleaving (LFI) on

Serial Links.]

• Changes to DDoS protection policers for PIM and PIMv6 (MX Series with MPCs,T4000with FPC5)—Starting in Junos OS Release 13.3R2, the default values forbandwidth and burst limits have been reduced for PIM and PIMv6 aggregate policers

to prevent starvation of OSPF and other protocols in the presence of high-rate PIM

activity.

Old ValueNew ValuePolicer Limit

20,0008000Bandwidth (pps)

20,00016,000Burst (pps)

To see thedefault andmodified values for DDoSprotection packet-typepolicers, issue

one of the following commands:

• show ddos-protection protocols parameters brief—Displays all packet-type policers.

• show ddos-protection protocols protocol-group parameters brief—Displays only

packet-type policers with the specified protocol group.

An asterisk (*) indicates that a value has beenmodified from the default.

• Changes to distributed denial of service statement and command syntax—Startingin Junos OS Release 13.3R2, the protocol group and packet type syntax has changed

for the protocols statement at the [edit system ddos-protection] hierarchy level and

for the various show ddos-protection protocols commands.

The filter-v4and filter-v6packet typeshavebeenmoved fromtheunclassifiedprotocol

group to the new filter-action protocol group.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/mlppp-link-services-understanding-mx.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/mlppp-link-services-understanding-mx.html

• filter-actionprotocol group—The followingpacket typesareavailable for unclassified

firewall filter action packets, which are sent to the host because of reject terms in

firewall filters:

• aggregate—Aggregate of all unclassified filter action packets.

• filter-v4—Unclassified IPv4 filter action packets.

• filter-v6—Unclassified IPv6 filter action packets.

• other—All other unclassified filter action packets that are not IPv4 or IPv6.

The resolve-v4 and resolve-v6 packet types have been removed from the unclassified

protocol group. They are replaced by the newmcast-v4,mcast-v6, ucast-v4, and

ucast-v6 packet types in the new resolve protocol group.

• resolve protocol group—The following packet types are available for unclassified

resolvepackets,whichare sent to thehostbecauseof a traffic request resolveaction:

• aggregate—Aggregate of all unclassified resolve packets.

• mcast-v4—Unclassified IPv4multicast resolve packets.

• mcast-v6—Unclassified IPv6multicast resolve packets.

• other—All other unclassified resolve packets.

• ucast-v4—Unclassified IPv4 unicast resolve packets.

• ucast-v6—Unclassified IPv6 unicast resolve packets.

• Deleting PTP clock client (MX104)—Starting with Junos OS Release 13.2, on MX104routers, when you toggle from a secure slave to an automatic slave or vice versa in the

configuration of a Precision Timing Protocol (PTP) boundary clock, youmust first

delete the existing PTP clock client or slave clock settings and then commit the

configuration. You can delete the existing PTP clock client or slave clock settings by

using the delete clock-client ip-address local-ip-address local-ip-address statement at

the [edit protocols ptpmaster interface interface-name unicast-mode] hierarchy level.

You can then addnewclock client configuration by using the set clock-client ip-address

local-ip-address local-ip-address statement at the [edit protocols ptpmaster interface

interface-name unicast-mode] hierarchy level and committing the configuration.

However, if you attempt to delete the existing PTP clock client and add the new clock

client before committing the configuration, the PTP slave clock remains in the free-run

state and does not operate in the auto-select state (to select the best clock source).

This behavior is expected when PTP client or slave settings are modified.

• Preventing the filtering of packets by ARP policers (MX Series routers)—Beginningin Junos OS Release 13.3R3, you can configure the router to disable the processing of

the specified ARP policers on the received ARP packets. Disabling ARP policers can

cause denial-of-service (DoS) attacks on the system. Due to this possibility, we

recommend that you exercise caution while disabling ARP policers. To prevent the

processing of ARPpolicers on the arriving ARPpackets, include the disable-arp-policer

statement at the [edit interfaces interface-name unit logical-unit-number family inet

policer] or the [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number family inetpolicer]hierarchy level. Youcanconfigure this statement



only for interfaces with inet address families and on MX Series routers with MPCs.

When you disable ARP policers per interface, the packets are continued to be policed

by the distributed DoS (DDoS) ARP policer. Themaximum rate of is 10000 pps per

FPC.

[See Applying Policers.]

Management

• Restrictions forcryptoalgorithmsforFIPS inOpenSSH—Starting in JunosOSRelease13.3, the following options are not allowed on systems operating in FIPSmode:

[edit system services ssh]set macs <algorithm>

Not allowed: hmac-md5, hmac-md5-96, [email protected],

[email protected], hmac-ripemd160,

[email protected], [email protected],

[email protected], [email protected], and

[email protected].

[edit system services ssh]set key-exchange <algorithm>

Not allowed: group-exchange-sha1, dh-group14-sha1, and dh-group1-sha1.

[edit system services]set hostkey-algorithm <algorithm | no-algorithm>

Not allowed: ssh-dss and ssh-rsa.

Prior to Junos OS Release 13.3, the options were available but should have been

disallowed.

MPLS

• Enhanced support for GRE interfaces for GMPLS (MX Series)—Starting in Junos OSRelease 12.3R7, on GRE interfaces for Generalized MPLS control channels, you can

enable the inner IP header’s ToSbits to be copied to theouter IP packet header. Include

the copy-tos-to-outer-ip-header statement at the [edit interfaces gre unit

logical-unit-number] hierarchy level. Previously, the copy-tos-to-outer-ip-header

statement was supported for GRE tunnel interfaces only.

[See copy-tos-to-outer-ip-header.]

• Enhanced transit LSP statistics collection—Starting in Junos OS Release 13.3R4,RSVP no longer periodically polls for transit LSP statistics. This change does not affect

the showmpls lsp statistics command or automatic bandwidth operations for ingress

LSPs. To enable the polling and display of transit LSP statistics, include the

transit-statistics-polling statement at the [edit protocolsmpls statistics] hierarchy

level. You cannot enable transit LSP statistics collection if MPLS statistics collection

is disabledwith theno-transit-statistics statementat the [editprotocolsmplsstatistics]

hierarchy level.

• In Junos OS releases prior to 13.3, you can configure both fast reroute and node and

link protection on the same LSP. Beginning in Junos OS Releases 13.3, you can still



http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/interfaces-applying-policers.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/copy-tos-to-outer-ip-header-edit-interfaces-sv.html

configure both fast reroute and node and link protection on the same LSP; however,

whenyouattempt to commit a configurationwhereboth featuresare enabled, a syslog

warning message displays that states: "The ability to configure both fast-reroute and

link/node-link protection on the same LSP is deprecated and will be removed in a

future release".

Multicast

• PIM snooping support using relaymode (M Series andMX Series)—Starting withJunos OS Release 13.3, PIM snooping on PE routers is supported using relay mode

insteadofproxymode.This enablesCE routerswithPIMsnooping to sendHellopackets

without setting the tracking bit (T-bit) to the PE routers. In relay mode, you need not

configurevalues for the join-prune-timeoutstatementandsave theFiniteStateMachine.

To check the status of relay mode on the CLI, use the show pim snooping neighbors

command or the show pim snooping interfaces command.

• Traffic arriving via IRBwhen configured in enhanced ip-mode—Beginningwith JunosOS Release 13.3, when configured in enhanced-ip mode, traffic arriving via IRB

(multic-ast source connected over Layer 3) is not forwarded to remote PEs in VPLS

when igmp-snooping is configured along with use-p2mp-lsp knob.


• Support of new system log by SNMP for notifying target addition (M Series, MXSeries, and T Series)—Beginning with Junos OS Release 13.3, when a new trap target

configuration is added to the agent, SNMP raises a new system log

SNMPD_TRAP_TARGET_ADD_NOTICE. The user can configure an event policy for this

system log event to raise a notification of the new trap target addition. This trap is sent

to all the configured trap targets including the new target.


• Newfirewall filtermatchconditionsupportedonMPClinecards(MXSeries)—StartinginRelease 13.3R2, JunosOSsupports the gre-key firewall filtermatch condition onMPC

line cards on MX Series 3D Universal Edge Routers. To configure the gre-key firewall

filter match condition, include the gre-key statement at the [edit firewall family inet

filter filter term term from] hierarchy level.

Routing Protocols

• Hidden clear commands—Starting in Junos OS Release 13.3, the purge option of theclear ospf database and clear ospf3 database commands is hidden and unsupported.

• BGP attribute flag bits—In Junos OS Release 13.2 and earlier, unused attribute flagbits were propagated unchanged. Starting in JunosOSRelease 13.3, BGP attribute flag

bits are reset to zerobydefault andnotpropagated. This behavior is being standardized,

as specified in Internet draft draft-hares-idr-update-attrib-low-bits-fix-01, Update

Attribute Flag Low Bits Clarification.

• Change inconfiguringkeepnoneandkeepallstatements—Starting in JunosOSRelease13.3, configuring keep none or keep all no longer causes all BGP sessions to restart. For



peers that do not support route refresh, when you configure keep none or keep all, the

associated BGP sessions are restarted (flapped). For peers that do support route

refresh, the local speaker sends a route refresh and performs an import evaluation. For

these peers, the sessions do not restart when you configure keep none or keep all. To

determine if a peer supports refresh, check for Peer supports Refresh capability in the

output of the showbgpneighbor command. In previous releases, configuring keepnone

or keep all caused all BGP sessions to restart.

• Starting in Junos OS 13.3, Junos OSmodifies the default BGP extended community

value used for MVPN IPv4 VRF route import (RT-import) to the IANA-standardized

value. Themvpn-iana-rt-import statement is the default. Themvpn-iana-rt-import

statement has been depricated and should be removed from configurations.


• Restriction forRPMprobetestdata-size—In JunosOSRelease 13.2andearlier releases,the data-size statement at the [edit services rpmprobeowner test test-name] hierarchy

level did not enforce any additional restrictions when the hardware-timestampwas

included. Starting in Junos OS Release 13.3, the data-size value must be at least 100

bytes smaller than the default MTU of the interface of the RPM client interface when

the hardware-timestamp statement is used.

[edit services rpm probe owner test test-name]hardware-time-stamp;data-size size;

• New ranges for TWAMP server connections—In Junos OS Release 13.2 and earlierreleases, themaximum-connections statement at the [edit services rpmtwampserver]

hierarchy level had a range of 1 through 2048. Starting in Junos OS Release 13.3, the

maximum-connections statement has a range of 1 through 1000. In Junos OS Release

13.2 and earlier releases, themaximum-connections-per-client statement at the [edit

services rpm twamp server] hierarchy level had a range of 1 through 1024. Starting in

Junos OS Release 13.3, the maximum-connections-per-client statement has a range

of 1 through 500.

• New range for data-size statement—In Junos OS Release 13.2 and earlier releases,the data-size statement at the [edit services rpmprobeowner test test-name] hierarchy

level had a range of 0 through65507. Starting in JunosOSRelease 13.3R1, thedata-size

statement has a range of 0 through 65400.

• Restriction for NAT ruleswith translation type stateful-nat-64—In JunosOSRelease13.2 and earlier releases, the following restriction was not enforced by the CLI: if the

translation-type statement in the then statement of a NAT rule was set to

stateful-nat-64, the range specified by the destination-address-range or thedestination-prefix-list in the from statement needed to be within the range specified

by thedestination-prefix statement in the then statement. Starting in JunosOSRelease

13.3, this restriction is enforced.

[edit services nat]rule rule-name {term term-name {from {destination-address-range lowminimum-value highmaximum-value <except>;



destination-prefix-list list-name <except>;}then {destination-prefix destination-prefix;

}}

}

• Change in runningRPMtraceoptions—Starting in JunosOSRelease 13.2, runningRPMtraceoptions is performed from the [edit services rpm] hierarchy. Prior to Junos OS

Release 13.2, running RPM traceoptions was performed at the [edit snmp] hierarchy.

The RPM traceoptions are configured as follows:

[edit services rpm]traceoptions {file filename <files number> <match regular-expression > <sizemaximum-file-size><world-readable | no-world-readable>;

flag flag;}

This issue was being tracked by PR857470.

• Restrictions for maximumblock size for NAT port block allocation—Beginning withJunos OS Release 13.3, the maximum blocksize for NAT port block allocation (PBA) is

32,000.

• Support for display of NAT type for EIF flows (MX Series routers with MS-MICs andMS-MPCs)—Starting with Junos OS Release 13.3R4, the output of the show services

sessionsextensive command, theTranslationType fielddisplays the valueasNAPT-44

for Endpoint Independent Filtering (EIF) flows. Also, the label, EIF, is displayed beside

the translation type parameter to enable easy identification of EIF flows.

• Support for passive-mode tunneling (MX Series routers with MS-MICs andMS-MPCs)—Starting with Junos OS Release 13.3R4, passive mode tunneling issupported on MS-MICs and MS-MPCs. You can include the passive-mode-tunneling

statementat the [editservicesservice-setservice-set-name ipsec-vpn-options]hierarchy

level to enable the service set to tunnel malformed packets.



NOTE: The header-integrity-check option that is supported onMS-MICs

andMS-MPCs to verify the packet header for anomalies in IP, TCP, UDP,and ICMPinformationandflagsuchanomaliesanderrorshasafunctionalitythat is opposite to the functionality caused by passivemode tunneling. Ifyou configure both the header-integrity-check statement and the

passive-modetunnelingstatementonMS-MICsandMS-MPCs,andattempt

to commit such a configuration, an error is displayed during commit.

The passivemode tunneling functionality (by including thepassive-mode-tunneling statement at the [edit services service-set

service-set-name ipsec-vpn-options] hierarchy level) is a superset of the

capability to disable IPsec tunnel endpoint in the traceroute output (byincluding no-ipsec-tunnel-in-traceroute statement at the [edit services

ipsec-vpn] hierarchy level). Passivemode tunneling also bypasses the

active IP checks and tunnel MTU check in addition to not treating an IPsectunnel as a next-hop as configured by the no-ipsec-tunnel-in-traceroute

statement.


• Upgrading Junos OS in one step (MX Series)—Starting in Junos OS Release 13.3, youcan specifymultiple configuration files in one stepwhen youupgrade JunosOSon your

device.Whenyouenter the requestsystemsoftwareaddor the requestsystemsoftware

validate command, you can use the upgrade-with-config option. You can also use the

upgrade-with-config-format option when the configuration file is in the text format.


• Subscriber loginwhen lawful intercept fails—Starting in JunosOSRelease 13.3, whenlawful intercept activation fails during a subscriber login, the subscriber login is not

denied.AnSNMPmessage is still generated that indicates the lawful interceptactivation

failed. In Junos OS releases prior to 13.2R2, the subscriber login was denied if lawful

intercept activation failed.

• Change to test aaa ppp user and test aaa dhcp user commands—Starting in Junos OSRelease 13.3, the test aaapppuser and test aaadhcp user commands no longer display

serviceactivation statusbecause serviceactivation is not required in these commands.

Inearlier releases, thecommandsdisplayedserviceactivationstatus to indicatewhether

service activation failed or succeeded. Service-related RADIUS attribute values are

still displayed.

• Configuring domainmaps to use the default routing instance (MXSeries)—Startingin Junos OS Release 13.3, on MX Series routers you can explicitly configure a domain

map to use the default (master) routing instance for the AAA or subscriber contexts.

This enhancement enables you to configure a domain map to use the default routing

instance in cases where a nondefault routing instance is currently referenced, or in

other scenarios in which you need to explicitly reference the default routing instance.



• Configuration support to prevent the LACPMC-LAG system ID from reverting to thedefault LACP system ID on ICCP failure—Beginning in Junos OS Release 13.3, you canconfigure the prefer-status-control-active statement with the status-control

standbyconfiguration at the [edit interfaces aeX aggregated-ether-optionsmc-ae]

hierarchy level to prevent the LACPMC-LAG system ID from reverting to the default

LACP system ID on ICCP failure. Use this configuration only if you can ensure that ICCP

does not go down unless the router is down. Youmust also configure the hold-time

down value (at the [edit interfaces interface-name] hierarchy level) for the interchassis

link with the status-control standby configuration to be higher than the ICCP BFD

timeout. This configuration prevents traffic loss by ensuring that when the router with

the status-control active configuration goes down, the router with the status-control

standby configuration does not go into standbymode.

• Support for rejecting IPv6CP negotiation in the absence of an authorized address(MX Series)—Starting in Junos OS Release 13.3, you can control the behavior of therouter in a situationwhere IPv6CP negotiation is initiated for subscriber sessionswhen

no authorized addresses are available. By default, IPv6CP negotiation is enabled to

proceed for an IPv6-only session when AAA has not provided an appropriate IPv6

address or prefix. In the absence of the address, the negotiation cannot successfully

complete. To prevent endless client negotiation of IPv6CP, include the

reject-unauthorized-ipv6cp statement at the [edit protocols ppp-service] hierarchy

level, which enables the jpppd process to reject the negotiation attempt.

• Support for ignoring DSL ForumVSAs from directly connected devices (MXSeries)—WhenCPEdevicesaredirectly connected toaBNG, youmightwant the router

to ignore any DSL Forum VSAs that it receives in PPPoE control packets because the

VSAs can be spoofed bymalicious subscribers. Spoofing is particularly serious when

the targeted VSAs are used to authenticate the subscriber, such as Agent-Circuit-Id

[26-1] and Agent-Remote-ID [26-2].

To ignore the DSL Forum VSAs, starting in Junos OS Release 13.3, include the

direct-connect statement for PPPoE interfaces or PPPoE underlying interfaces at the

following hierarchy levels:

• [editdynamic-profilesprofile-name interfacesdemux0unit logical-unit-number family

pppoe]

• [editdynamic-profilesprofile-name interfaces interface-nameunit logical-unit-number

family pppoe]

• [editdynamic-profilesprofile-name interfaces interface-nameunit logical-unit-number

pppoe-underlying-options]

• [edit interfaces interface-name unit logical-unit-number family pppoe]

• [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number family pppoe]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number pppoe-underlying-options]



You can determine whether direct-connect is configured for particular interfaces by

issuing the show interfaces or show pppoe underlying-interfaces command.

• ANCP agent behavior for invalid generic responsemessages (MX Series)—Startingin Junos OS Release 13.3, when the ANCP agent receives an incorrect or unexpected

generic responsemessage from an ANCP neighbor, it immediately drops the packet,

generates a system log notice message, and takes no further action.

• Changes toANCPshowcommandoutput (MXSeries)—Starting in JunosOSRelease13.3, the show ancp neighbor command displays information for all configured ANCP

neighbors regardless of operational state. In earlier releases, it displayed information

only for neighbors in the Established state. The Time field, which displays the elapsed

time since the neighbor entered its current state, has replaced the Up TIme field. An

asterisk (*) prefixed to the neighbor entry indicates that the adjacency information

might be stale.

In Junos OS Release 13.3 and later, the show ancp subscriber command displays

information for all subscribers regardless of operational state. In earlier releases, it

displayed information only for active subscribers in the Established state. An asterisk

(*) prefixed to the subscriber entry indicates that the information might be stale. Two

asterisks (**) indicate that the neighbor associated with the subscriber has lost its

adjacency.

• Enhancedaccountingstatistics (MSeries,MXSeries,andTSeries)—Starting in JunosOSRelease 13.3, the shownetwork-accessaaastatisticsaccounting command includes

the optional detail keyword, which provides additional information about the RADIUS

accounting statistics. You can use the enhanced details for troubleshooting

investigations.

[See Verifying andManaging Subscriber AAA Information.]

• Support for processing Cisco VSAs in RADIUSmessages for serviceprovisioning—Starting with Junos OS Release 13.3R3, Cisco VSAs are supported forprovisioning andmanagement of services in RADIUSmessages, in addition to the

supported Juniper VSAs for administration of subscriber sessions. In a deployment in

which a customer premises equipment (CPE) is connected over an access network to

a broadband remote access gateway, the Steel-Belted Radius Carrier (SBRC)

application might be used as the authentication and accounting server using RADIUS

as theprotocol and theCiscoBroadHopapplicationmightbeusedas thePolicyControl

and Charging Rules Function (PCRF) server for provisioning services using RADIUS

change of authorization (CoA)messages. Both the SBRC and the Cisco BroadHop

serversare considered tobeconnectedwith thebroadbandgateway in sucha topology.

By default, service accounting is disabled. If you configure service accounting using

both RADIUS attributes and the CLI interface, the RADIUS setting takes precedence

over the CLI setting. To enable service accounting using the CLI, include the accounting

statement at the [edit access profile profile-name service] hierarchy level. To enable

interim service accounting updates and configure the amount of time that the router

waits before sending a new service accounting update, include the update-interval

minutes statement at the [edit accessprofileprofile-name serviceaccounting]hierarchy

level.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/command-summary/show-network-access-aaa-statistics.html

Youcanconfigure the router tocollect timestatistics, or bothvolumeand timestatistics,

for the service accounting sessions beingmanaged byAAA. To configure the collection

of statistical details that are time-based only, include the statistics time statement at

the [edit access profile profile-name service accounting] hierarchy level. To configure

the collection of statistical details that are both volume-time-based only, include the

statistics volume-time statement at the [edit access profile profile-name service

accounting] hierarchy level.

• Specifying the UDP port for RADIUS dynamic-request servers—Beginning in JunosOS Release 13.3, you can define the UDP port number to configure the port on which

the router that functions as theRADIUSdynamic-request servermust receive requests

from RADIUS servers. By default, the router listens on UDP port 3799 for dynamic

requests from remote RADIUS servers. You can configure the UDP port number to be

used for dynamic requests for a specific access profile or for all of the access profiles

on the router. To define the UDP port number, include the dynamic-request-port

port-number statement at the [edit access profile profile-name radius-server

server-address] or the [edit access radius-server server-address] hierarchy level.

• DCHP Relay subscriber and proxy-mode support (MX Series)—Starting with JunosOS Release 13.3, when DHCP Relay Agent for subscriber management is configured in

proxy-mode, DHCP Request packets for which no client/subscriber state exists on the

Relay Agent (stray requests) behave according to RFC 2131 Section 4.3.2: “If the DHCP

server hasno recordof this client, then itMUST remain silent, andMAYoutputawarning

to the network administrator. This behavior is necessary for peaceful coexistence of

non-communicatingDHCP servers on the samewire.” Suchbehavior also occurswhen

multiple, non-communicating, proxy-modeRelayAgentsareprocessingDHCPRequest

packets from the same client or subscriber. In some network configurations, Relay

Agent can send a NAK to the client or subscriber when Relay Agent is not configured

to act on bind-on-request. The NAK prevents Relay Agent from forwarding the DHCP

Request to the server or, in the case of a client move, when the packet is not directed

to the proxy-mode Relay Agent that receives it. DHCP Relay Agent for subscriber

management no longer generates a NAK in place of the server in response to stray

requests but relies on the server to respond appropriately to the client or subscriber.

For those cases when packets are configured not to be forwarded to the server

(no-bind-on-request is configured), orwhen thepacket isdeterminednot tobedirected

to the receiving Relay Agent, those packets are silently discarded in accordance with

RFC 2131 Section 4.3.2.

• Addition of pw-width option to the nas-port-extended-format statement—Starting inJunosOSRelease 13.3R4, you can configure the number of bits for the pseudowire field

in the extended-format NAS-Port attribute for Ethernet subscribers. Specify the value

with thepw-widthoption in thenas-port-extended-format statementat the [editaccess

profile profile-name radius options] hierarchy level. The configured fields appear in the

following order in the binary representation of the extended format:

aggregated-ethernet slot adapter port pseudo-wire stacked-vlan vlan

The width value also appears in the Cisco NAS-Port-Info AVP (100).




• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in the CLI (M Series, MX Series, and T Series)—Junos OS reserves the prefixjunos- for the identifiersofconfigurationsdefinedwithin the junos-defaultsconfiguration

group. User-defined identifiers cannot start with the string junos-. If you configured

user-defined identifiers using the reserved prefix through a NETCONF or Junos XML

protocol session, the commit correctly fails. Prior to Junos OS Release 13.3, if you

configureduser-defined identifiers through theCLI using the reservedprefix, thecommit

incorrectly succeeded. Junos OS Release 13.3 and later releases exhibit the correct

behavior. Configurations that currently contain the reserved prefix for user-defined

identifiers other than junos-defaults configuration group identifiers will now correctly

result in a commit error in the CLI.

• Change in show version command output (M Series, MX Series, and TSeries)—Beginning in JunosOSRelease 13.3, theshowversioncommandoutput includesthe new Junos field that displays the Junos OS version running on the device. This new

field is in addition to the list of installed sub-packages running on the device that also

display the Junos OS version number of those sub-packages. This field provides a

consistent means of identifying the Junos OS version, rather than extracting that

information from the list of installed sub-packages. In the future, the list of

sub-packagesmight not be usable for identifying the Junos OS version running on the

device. This change inoutputmight impact existing scripts thatparse information from

the show version command.







user@host> show versionHostname: lab Model: mx960 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...

user@host> show versionHostname: lab Model: mx960 JUNOS Base OS boot [12.2R2.4]JUNOS Base OS Software Suite [12.2R2.4]JUNOS Kernel Software Suite [12.2R2.4]JUNOS Crypto Software Suite [12.2R2.4]...

[See show version.]

• In all supported Junos OS releases, regular expressions can no longer be configured if

they require more than 64MB of memory or more than 256 recursions for parsing.




















Known Behavior

This sectioncontains theknownbehavior, systemmaximums, and limitations inhardware

and software in Junos OS Release 13.3R4 for the M Series, MX Series, and T Series.







• If you definemore than one forwarding class for a given queue number, do not use the

nameofadefault forwardingclass for oneof thenewclasses, becausedoing socauses

the forwarding classwith thedefault name tobedeleted. For example, donot configure

the following, because doing so deletes the best-effort class:

user@host# set class-of-service forwarding-classes class be queue-num0user@host# set class-of-service forwarding-classes class best-effort queue-num0user@host# commit





• The MPC5E, MPC5EQ, and MP6E cards do not support unified ISSU on an MX Series

Virtual Chassis.


• The clear pppoe sessions command does not have an all option and consequently

clears all current PPPoE subscriber sessions when you enter the command. The CLI

does not prompt you to confirm that you want to clear all sessions. When you want to

gracefully terminateasubscriber session, always include the interfacenameassociated

with the session. For some network configurations, if your subscribers have unique

usernames, youcanalternatively issue theclearnetwork-accessaaasubscriberusername

command.

• On the MX Series, subscriber management uses firewall filters to capture and report

the volume-based service accounting counters that are used for subscriber billing. You

must always consider the relationship between firewall filters and service accounting

counters, especially when clearing firewall statistics. When you use the clear firewall

command (to clear the statistics displayed by the show firewall command), the

commandalso clears the service accounting counters that are reported to theRADIUS

accounting server. For this reason, youmust be cautious in specifying which firewall

statistics you want to clear. When you reset firewall statistics to zero, you also zero

the counters reported to RADIUS.

• On the MX Series, subscriber management provides a route suppression feature that

enables you to override the DHCP default behavior that adds access-internal and

destination routes for DHCPv4 sessions, and to access-internal and access routes for

DHCPv6 sessions. However, you cannot suppress access-internal routes when the

subscriber is configuredwithboth IA_NAand IA_PDaddressesover IPdemux interfaces,

because the IA_PD route relies on the IA_NA route for next-hop connectivity.

• The “ConfiguringTunnel InterfacesonMXSeriesRouters” topic in theServices Interfaces

Configuration Guide fails to state that Ingress queuing and tunnel services cannot be

configured on the sameMPC as it causes Packet Forwarding Engine forwarding to

stop. Each feature can, however, be configured and used separately.










Known Behavior

Known Issues

This section lists the known issues in hardware and software in Junos OSRelease 13.3R4

for the M Series, MX Series, and T Series.




• Forwarding and Sampling on page 64




• Layer 2 Features on page 67

• MPLS on page 67


• Platform and Infrastructure on page 69





• VPNs on page 72


• COSD errors are seen while Routing Engine switchover without GRES enabled.

PR827534

• COSD errors - COSD_GENCFG_WRITE_FAILED: GENCFGwrite failed (op, minor_type)

= (add, policy inline) for tbl 4 if 7454 &str-4/2/0 Reason: File exists are during Routing

Engine switchover. PR827538

• CoS relevant misconfiguration (e.g. configure classifier exp for LT interfaces implicitly

using "interface all"way)might cause cosd crash. If cosd experiencesmultiple crashes

within a short time, it might not be able to restart. PR969900

• Sometimes MX Series responds with "no such instance" of the second OID when two

CoS OIDs are in the single SNMP packet. PR1015342

Forwarding and Sampling

• Accounting-data log file contains multiple header lines. PR881832

• Whenwe configure unsupported firewall filter on channelized interfaces, commit error

message showwithout this fixwasmisleading.With this fix, commit errorwill have the

following message: mgd: error: layer2-policer is not supported for interface so-3/2/0.

PR897975




https://prsearch.juniper.net/PR827534







• Deactivating Inline Jflow configuration does not makememory release normally.

PR1013320

• ARP policer applied on irb interface showsmessages as invalid path element

'disable_arp_policer'. PR1014598

General Routing

• next-hop-group knob is not supported under routing-instance hierarchy, but this knob

is present under this hierarchy. This PR is opened to removenext-hop-group knob from

routing-instance hierarchy. PR731264

• Openflowddoesnot supportprocess restartanddoesnot reconnect todfwd.PR838759

• PPPoE IPv6access routermightnot respond to the first ICMPv6RSmessage.PR869212

• The flat accounting files are made compliant to the documentation described XML

schema. PR902019

• When the NSR switchover happened immediately after a lot of vrf routing-instances

were being deleted, garbage lsi interfaceswill remain in kernel, while they are removed

from RPD. Those garbage interfaces will result KRT queue stack issue upon later lsi

re-configuration. PR912861

• PIC removal without offline of the PIC can cause FPC core in case of

10x10GE(LAN/WAN) SFPP PIC. PR922655

• Added AI-Scripts workaround for Junos OS bug sw-ui-misc/920478 (FIPS crash).

PR932644

• Destination ERR alarm not getting cleared even after FPC offlined. When the fpc for

which dest error was recorded is offlined, the src fpc will get the destination control

message. In the dest ctl vector we should clear the dest error alarm if there is no other

dest error reported from this fpc. As of now, the clear alarm call is missing. Because of

this alarmsare not getting cleared. In case of plane control, there is a call to clear alarm

and it works fine for sib offline scenarios. PR937862

• When a router is booted with AE having per-unit-scheduler configuration and hosted

on an EQ DPC, AE as well as its children get default traffic control profile on its control

logical interface. However, if a non-AE GE interface is created on the DPCwith

per-unit-scheduler configuration, itwill get default schedulermapon its control logical

interface. PR946927

• The SNMP Get, GetBulk, or GetNext request response for lldpPortConfigTable was

not filtering out the information of interfaces that are configured in the filter-interfaces

statement at the [edit snmp] hierarchy level. PR946975

• MPLS traceroute causes "rttable-mismatch" syslog messages. PR960493

• OnMX Series DPC line cards with redundancy System Control Boards (SCBs), when

active SCB goes down ungracefully by an unexpected event (such as turn off Power

Entry Modules (PEMs)), traffic loss is observed and cannot be recovered on standby

SCB as expected. PR961241

• "show chassis fabric topology" displays error when HSL2 link fault is between F13 and

F2S. PR962268


Known Issues
















• OnT4000withType-5FPC(T4000-FPC5-3D), if asingle request timeoutoroccasional

timeoutswere seenover longperiodof time, the timeouterrorbit is not clearedcorrectly.

This leads to destination bemarked dead, and the traffic cannot flow from source

Packet Forwarding Engine to destination Packet Forwarding Engine . PR963467

• Whenmirror destination interface is a next-hop-subgroup and enhanced-ip chassis

knob is enabled, family any mirroring applied on Layer3 interfaces ( inet/inet6 ) might

not work in certain scenarios. PR972138

• When a static discard route is configured with no-install option but actual forwarding

using different next hop, if egress sampling is enabled on the forwarding outgoing

interface (OIF), traffic leaving that interface would have incorrect OIF on the flow

records, resulting in unreliable flow records and incorrect billing. There is no traffic

impact though. PR1002287

• WithNSRenabled,whenactivatingaBGPsession ina routing instance,and the interface

route is imported into the main routing instance, the TCP receive windowmight

decrement until it hits 0, after receiving incomingBGP traffic that arrives from themain

routing instance. PR1003576

• A raw IP packet with invalid Memory Buffer (mbuf) length may trigger a kernel crash.

The invalid mbuf length might be set by other daemons incorrectly. PR1006320

• The routingprotocol process (rpd)might crashcontinuouslywith core filesuponadding

a sub-interface with "disable" configuration to a MC-LAG interface. PR1014300

• Noperformance or functional impact. Can be safely ignored. "Ignore the PTPmessage

(2) as this MPC doesn't support EEC" should bemoved from notice to debug level.

PR1020161

• In BGPMVPN RPT-SPTmode, on an egress PE with an interface with static IGMP v2

configured and directly connected IGMP v2 hosts, the IGMP reports can be treated as

multicast data packets by Packet Forwarding Engine and it can trigger data events

(IIF-MISMATCH) that can create undesirable (S,G) states. These states are usually

harmless but, in a high scale, can result in resource utilization. It is worth noting that in

BGPMVPNRPT-SPTmode, directly connected receivers and senders are not officially

supported for other reasons (due to lack of SPT-Switch capability). PR1021501


• Duringa router hardwareupgradeprocedure, in dualRoutingEngines system, thenewly

installed Routing Engine may overwrite the other Routing Engines configuration with

the factory default configuration. As a result, both Routing Engines may boot up in

"Amnesiac" mode. This situation can occur under following conditions: - RE0 has

default factory configuration and, - RE1 has "commit synchronize" enabled - Both RE0

and RE1 boot-up simultaneously, or - RE0 is UP and running and RE1 is restarted.

PR909692

• If NSR Routing Engine switchover is done right after committing the configuration

changewhichdeletes routing-instance(s), someof those instanceswill not bedeleted

from forwarding table. PR914878














• For Automatic Protection Switching (APS) on SONET/SDH interfaces, there are no

operational mode commands that display the presence of APSmodemismatches.

AnAPSmodemismatch occurswhen one side is configured to use bidirectionalmode,

and the other side is configured to use unidirectional mode. PR65800

• Ethernet OAM: Ethernet Loopback test can only be performed if MAC DA is known in

the MAC table. PR879358

• Customer may observe a traffic spike for few seconds on virtual circuit shaping when

doing GRES. PR925327

• PPPoA session would not come up on removal/addition of cable to the tester port.

PR939404

• Demux Subscriber IFLs might show the interface as 'Hardware-Down' even though

the underlying ae bundle and its member link show up. PR971272

• In thePPPoEenvironment,when the subscriber logs in successfully but profile activate

fails, due to code processing error, the address entry is not deleted in the authd's DAP

pool. So when the subscriber tries to log in again, it connects fails. PR995543

• InEthernetOAMconnectivity-fault-management, JunosOSdefault encodesMAID(MD

name and MA name) in character format. Currently only 43 octets are supported in

Junos OS for the MD +MA name. Junos OS needs to support amaximum length of 44

octets for MAID per the standards. PR997834

• When IEEE 802.3ah OAM link-fault management action profile is configured to define

an event and the resulting action, the link might flap after it is brought down by an

event but brought up by other events erroneously. PR1000607

Layer 2 Features

• When toggling VLAN tagging type from "flexible-vlan-tagging" to "vlan-tagging" or

vice versa, the integrated bridging and routing (IRB) MTU should be changed

accordingly. However the IRB MTU is not re-computed in this case, which might lead

to connectivity outage. PR928746

• InMXSeriesVirtualChassis (MXVC)scenariowithLACPconfiguration. In rare condition,

after VC-M chassis power down, the LACP state gets stuck in ATTACHED state, and

all traffic carried over these affected access LAGs are blackholed. PR959041

• After configuration change or convergence, kernel may report ifl_index_alloc failures

causing KRT queue ENOMEM issue, eventually preventing new logical interfaces from

being added to the system. PR997015

MPLS

• For point-to-multipoint LSPs configured for VPLS, the "ping mpls" command reports

100 percent packet loss even though the VPLS connection is active. PR287990

• In current JunosOS, lsping/lsptrace utilities have compatibility issuewith other vendor

routers. Millisecond field might show huge value which results in incorrect RTD being


Known Issues













calculated. Juniper-MX960>pingmpls ldp 192.168.228.7/32 source 192.168.199.193/32

exp 5 count 5 size 100 detail Request for seq 1, to interface 510, label 1102, packet size

100 Reply for seq 1, return code: Egress-ok, time: 3993729.963ms <--- Local transmit

time: 2013-04-29 12:05:06 IST873.491msRemote receive time: 2013-04-29 12:05:06

IST3994603.454<----This is cosmetic issueandcurrent software limitation.PR891734

• Although NSR does not support MPLSOAMD and it does not run on backup Routing

Engine, backup RPD is attempting to do task_connect to MPLSOAMD. This behavior

causes periodical message popping up on backup Routing Engine. Feb 21 15:14:13.306

2014mx480-re1 rpd[2840]: task_connect: task MPLSOAMD

I/O./var/run/mplsoamd_control addr /var/run/mplsoamd_control: No such file or

directory. PR938284

• Ifweset the followingconfigurationandenter the"showmplsadmin-groups-extended"

command, we can see this issue. In this case, we don't set "admin-groups" for

"admin-groups-extended-range". << conifg >> set routing-options

admin-groups-extended-rangeminimum 50 set routing-options

admin-groups-extended-rangemaximum 300 set protocols mpls interface all <<

show command >> lab@cheese# run showmpls admin-groups-extended error:

timeout communicating with routing daemon <<<<<<<<<<<<<<<<<<We need to

wait this message about 30 seconds - 60 seconds. PR966613

• When we set the following configuration, we can see this issue. << configuration >>

set routing-options admin-groups-extended-rangeminimum 2147483647 set

routing-options admin-groups-extended-rangemaximum 3500000000 set

routing-options admin-groups-extended test1 group-value 2147483647 set

routing-options admin-groups-extended test2 group-value 2147483648 set protocols

mpls interface all << show command >> lab@cheese# run showmpls

admin-groups-extended Group Value test1 2147483647 test2 -2147483648

<<<<<<<<<<<<<<<< Extended administrative groups range: [

2147483647..-794967296 ] <<<<<<<<<<<<<<< PR966615

• In l2circuit scenario with LDP session established between Juniper Networks PE and

Cisco PE, if Cisco PE is not sending a label withdraw for the l2circuit Forwarding

Equivalence Class (FEC) before advertising a new label for it, and later, when Cisco

PE tries to change the l2circuit parameters, the rpd process might crash on Juniper

Networks PE. This issue does not occur in Junos OS environment as it always sends a

label withdraw before advertisement of new label. PR1016270









• When syslog server is configured using hostname, after Routing Engine switchover

router stopped sending the syslogs to external syslog server. Immediately after

switchover, DNS was not accessible because it will take some time to learn route to

DNS. System stopped retrying DNS resolution and syslogging stopped. Systemwas

running GRES (no NSR). PR947869


• When scripts are synchronized from one Routing Engine to the other, the destination

for the scripts in the other Routing Engine should be based on the configuration on the

other Routing Engine. This issue prevents this from happening and destination for

scriptsdependson thecurrentRoutingEngine fromwhich thescriptsweresynchronized

instead of the configuration on the other Routing Engine. PR841087

• OnallMXSeriesdevices,whena router is actingasanNTPbroadcast server, broadcast

addresses must be in the default routing instance. NTPmessages are not broadcast

when the address is configured in aVPNvirtual routing and forwarding (VRF) instance.

PR887646

• The jcs:dampen() function will not perform correctly if the system clock is moved to

an earlier time. PR930482

• Backing up the configuration with transfer-on-commit does not work in an MX-VC

environment. PR947444

• With FPC3-E3 type FPC, the internal pc- interface statistics on the IQ/IQ2 PIC will be

the same as the ingress interface statistics of the physical interface if family mpls is

configured. It is a cosmetic display issue. PR953183

• TheGNUdebugger, gdb, canbeexploited inaway thatmayallowexecutionof arbitrary

unsigned binary applications. PR968335

• In multi-chassis platform, one of LCC's mastership change causes other LCC's

SPARE-SIB's Active-LED to be set abnormally instead of "actual active plane's LED".

There is no impact on operation, it is a cosmetic issue. * only if spare-SIB is SIB#0. For

example, - SCC-RE0(M),RE1(B) | LCC0-RE0(M),RE1(B) | LCC1-RE0(M),RE1(B) -

all-chassis SIB0 is spare status. - LCC0'smastership changemakes the issue on LCC1.

- LCC1's spare-SIB0's active LED to be set abnormally. PR972457

• XML traceroute does not display as-numbers. PR988727

• MPLS traffic going through the ingress pre-classifier logic may not determine mpls

payload correctly classifyingmpls packet into control queue versus non-control queue

and expose possible packet re-order. PR1010604

• On the MX2020 platform, the systemmight fail to replicate multicast packets to the

downstream interface located on the FPC slot 12 or above. There is no workaround.

PR1019414

• The error logs "?CHASSISD_FCHIP_CONFIG_MD_ERROR?will appear during FPC

normal boot up time and also during FPC restart time for each plane and for each

gimlet FPC. Problem statement: Ths Error logs


Known Issues












"?CHASSISD_FCHIP_CONFIG_MD_ERROR? are observed only in M320 chassis

containing FPCs based on Gimlet chipsets. Due to this error logs, the rate limit for the

fabric port connecting the Packet Forwarding Engine 1 will be set to the default values.

PR1020551

Routing Protocols

• When you configure damping globally and use the import policy to prevent damping

for specific routes, and a peer sends a new route that has the local interface address

as the next hop, the route is added to the routing table with default damping

parameters, even though the import policy has a non default setting. As a result,

damping settings do not change appropriately when the route attributes change.

PR51975

• Continuous soft core-filemay be observed due to bgp-path-selection code. RPD forks

a child and the child asserts to produce a core-file. The problem iswith route-ordering.

And it is auto-corrected after collecting this soft-assert-corefile, without any impact

to traffic/service. PR815146

• When a Bidirectional Protocol Independent Multicast (PIM) rendezvous point (RP) is

configured on a physical interface, such as fe-0/0/0 not the loopback interface, after

restarting the routing, theReversePathForwarding (RPF) interfacemightnotbeadded

to the accepting interface list for the affected groups, then some traffic can not be

forwarded normally. PR842623

• Prefixes thataremarkedwith twoormore route target communities (matchingmultiple

configured targets configured in policies) will be using more CPU resources. The time

it takes toprocess this kindofprefixesdependson thenumberofVRFsand thenumber

of routes that are sharing this particularity. This can lead to prolonged CPU utilization

in RPD. PR895194

• If Node-link protection is required in case of multiple ECMP primary paths, Node-link

protection command: ("setprotocols ospf area<area_Id> interface<interface_name>

node-link-protection") needs to be configured on all the outgoing-interfaces of

PLR(Point of Local Repair)node that fall on the ECMP path to the primary. For eg.in

the following diagram: PLR: RTA Destination: RTC Primary paths:

RTA-->lt-1/2/10.102-->RTB-->lt-1/2/10.203-->RTC;

RTA-->lt-1/2/10.122-->RTB-->lt-1/2/10.203-->RTC; Outgoing interfaces on PLR:

lt-1/2/10.102 lt-1/2/10.122Node-linkprotectionneeds tobeenabledonboth lt-1/2/10.102

and lt-1/2/10.122 if backup route avoiding RTB needs to be computed. (cost 1)

|-----|-------------lt-1/2/10.102(81.1.2.2 )----------------|-----| | | (cost 1) | | | RTA

|-------------lt-1/2/10.122(82.11.22.2)----------------|RTB | |_____| |_____| | | | |lt-1/2/10.203

|81.3.3.3 | | (cost 1000) |-----| | |----lt-1/2/10.103(81.1.3.1) -----| RTC |--------------------|

|-----| The behavior is corrected from release 14.1 and Node-link protection can be

configured on any one of the interfaces on the ECMP path. PR924290

• In a scaled setup, a restart routing or NSR switchover can result in duplicate msdp

entries. PR977841

• When all the following conditions are met, if the knob "path-selection

always-compare-med" is configured, the rpd process might crash. - routing-instance

(VR, VRF) with no BGP configuration - rib-group in default instance with










routing-instance.inet.0 as secondary-rib - rib-group applied to BGP in default instance

- BGP routes frommaster tables (inet.0) leaked to the routing-instance table

(routing-instance.inet.0). PR995586

• When inet.3/inet6.3 is not enabled, BGP group uses inet6.0 table to advertise the

routes for both inet6 unicast and inet6 labeld-unicast families. When BGP family is

changed, BGP sessions re-establish. When BGP starts to advertise routes to the peer,

BGP expects to see route label; However, if the old inet6 unicast routes are still present

(not completely cleaned), then rpd process crashes. The fix is to separate bgp group

for inet6 unicast with inet6 labeled-unicast with same rib. The old peers are cleaned

up in the old group and new peers are established in the new group. Thus, new peer

establishment is not delayed by the cleanup of the old peer. PR1011034

• Under certain sequence of events, RPD can assert after a RPD_RV_SESSIONDOWN

event. PR1013583


• When you specify a standard application at the [edit security idp idp-policy

<policy-name> rulebase-ips rule <rule-name>match application] hierarchy level, IDP

does not detect the attack on the nonstandard port (for example, junos:ftp on port

85). Whether it is a custom or predefined application, the application name does not

matter. IDP simply looks at the protocol and port from the application definition. Only

when traffic matches the protocol and port does IDP try to match or detect against

the associated attack. PR477748

• When IPsec tunnels scaledwe need to havemultiple proposals, otherwise all of these

tunnels do rekey almost around the same time, so load on the kmdwould be too high

to handle it. Currently kmd (Routing Engine) is limited by tunnel setup rate of 6 tnl/sec.

So, 1k tunnels bring up would take around 150-200 seconds . It is better to split the

configuration with different proposals (each with 1k) having different lifetime values ,

scattered by 200 seconds. PR929693

• If a destination-prefix or source-prefix is used like below example. The nat rule and

term names will be used to generate an internal jpool with a form :

_jpool_{rule_name}_{term_name}. If the generated jpool name exceeds 52 characters

in length it will get truncated. If the truncated jpool name gets overlapped with other

generated jpool name, it will lead to an inconsistent pool usage. user@router# show

services nat rule A_RULE_NAME_WHICH_IS_LONG_12345 { ... term

A_TERM_ALSO_WITH_LONG_NAME_1 { from{ source-address { 10.20.20.1/32; } } then

{ translated { source-prefix 10.10.10.1/32; <--- translation-type { source static; } } } }

term A_TERM_ALSO_WITH_LONG_NAME_2 { from { source-address { 10.20.20.1/32;

} } then { translated { source-prefix 10.10.10.2/32; <--- translation-type { source static;

} } } } } First jpool =

_jpool_A_RULE_NAME_WHICH_IS_LONG_1234_A_TERM_ALSO_WITH_LONG_NAME_1

> 52 characters. Second jpool =

_jpool_A_RULE_NAME_WHICH_IS_LONG_1234_A_TERM_ALSO_WITH_LONG_NAME_2

> 52 characters. The resulted jpool

"_jpool_A_RULE_NAME_WHICH_IS_LONG_1234_A_TERM_ALSO_WITH_" will be used

wrongly in both terms. PR973465

• L2TP LNS dropped all tunnels/sessions after a commit. PR1020420


Known Issues









• Filesystem corruption might lead to Routing Engine boot up failure. This problem is

observedwhen directory structure on hard disk (or SSD) is inconsistent. Such a failure

shouldnot result inbootupproblemnormally, butdue to the softwarebug theaffected

Junos OS releases mount /var file system incorrectly. The affected platforms are

M/T/MX/TX/TXP. PR905214


• Selecting the Monitor port for any port in the Chassis Viewer page takes the user to

the common Port Monitoring page instead of the corresponding Monitoring page of

the selected port. PR446890

• User needs to wait until the page is completely loaded before navigating away from

the current page. PR567756

• The J-Web interface allows the creation of duplicate term names in the Configure >

Security > Filters > IPV4 Firewall Filters page. But the duplicate entry is not shown in

the grid. There is no functionality impact on the J-Web interface. PR574525

• Using the Internet Explorer 7browser,while deletingauser fromtheConfigure>System

Properties >UserManagement >Users page on the J-Web interface, the system is not

showing warning message, whereas in the Firefox browser error messages are shown.

PR595932

• If you access the J-Web interface using the Microsoft InternetWeb browser version 7,

on the BGP Configuration page (Configure > Routing > BGP), all flagsmight be shown

in the Configured Flags list (in the Edit Global Settings window, on the Trace Options

tab) even though the flags are not configured. As aworkaround, use theMozilla Firefox

Web browser. PR603669

• On the J-Web interface, next hop column in Monitor > Routing > Route Information

displays only the interface address and the corresponding IP address is missing. The

title of the first columndisplays "static routeaddress" insteadof "DestinationAddress."

PR684552

• On HTTPS service J-Web is not launching the chassis viewer page at Internet Explorer

7. PR819717

• Onconfigure->clitools->point and click->system->advanced->deletion of saved core

context on "No" option is not happening at J-Web. PR888714

VPNs

• Whenyoumodify the frame-relay-tcc statementat the [edit interfaces interface-name

unit logical-unit-number] hierarchy level of a Layer 2 VPN, the connection for the

second logical interface might not come up. As a workaround, restart the chassis

process (chassisd) or reboot the router. PR32763

• BGP community 0xFF04 (65284) is a well known community (NOPEER), but it is

incorrectly displayed as "mvpn-mcast-rpt" in the cli command "show route". This is a













show command issue only. No operational misbehavior will be observed on the

router/network. PR479156

• In the Rosen MVPN environment, the RP-PE is an assert loser, another PE is sending

traffic over the data-mdt. If a new receiver PE with higher rate comes up, because

internal workflow processes incorrectly, the receiver PEmight reset data-mdt. This

leads to traffic loss. PR999760

• In the 12.3 release after issuing a "request pimmulticast-tunnel rebalance" command,

the software may place the default encapsulation and decapsulation devices for a

rosen MVPN on different tunnel devices. PR1011074









Resolved Issues

This section lists the issues fixed in the Junos OSmain release and themaintenance

releases.







Resolved Issues


• The syslogmessage "UI_OPEN_TIMEOUT: Timeout connecting to peer" might appear

if "show version detail" command is executed. This log is a cosmetic log and can be

ignored. This issue is fixed from Junos OS Release 13.3 onwards. PR895320


• OnMX Series routers with both MX linecard (in this case, MPC and MPCE on the box)

and other type linecard (DPCE on the box). When the Default Frame Relay DE Loss

Priority Map is configured and commited, all FPCs are getting restarted with

core-files.PR990911


Resolved Issues







• SNMPget-request for OID jnxCosIngressQstatTxedBytes (ingress queue)might return

the value of jnxCosQstatTxedBytes (egress queue). But SNMPwalk works fine since

it uses get-next-request. PR1011641


• Whena firewall filter hasoneormore termswhichhaveMXSeries-onlymatchcondition

or actions, such filters will not be listed during SNMP query. This behavior is seen

typically after Routing Engine reboot/upgrade/master-ship switch. Restarting mib2d

process will cause to learn these MX Series-only filters: cli > restart mib-process After

mib2d restart, SNMPmib walk of firewall OIDs will: - list all the OIDs corresponding

this MX Series-only filter - count correctly as configured in the filter Now, despite the

SNMPmib walk for firewall OIDs lists all OIDs and appropriate values, messages logs

will report the following logs for every interface that has this MX Series-only filter

applied. > Jul 8 15:52:09 galway-re0mib2d[4616]:

%DAEMON-3-MIB2D_RTSLIB_READ_FAILURE: get_counter_list: failed in reading

counter namesae33.1009-i: 288 (No such file or directory)> Jul 8 15:52:09galway-re0

mib2d[4616]: %DAEMON-3-MIB2D_RTSLIB_READ_FAILURE: get_counter_list: failed

in reading counter names ae31.1004-i: 257 (No such file or directory) > Jul 8 15:52:09

galway-re0mib2d[4616]: %DAEMON-3-MIB2D_RTSLIB_READ_FAILURE:

get_counter_list: failed in reading counter names ae33.1010-i: 289 (No such file or

directory) > Jul 8 15:52:09 galway-re0mib2d[4616]:

%DAEMON-3-MIB2D_RTSLIB_READ_FAILURE: get_counter_list: failed in reading

counter names ae31.1004-i: 257 (No such file or directory) The above two issues are

addressed in this PR fix. PR988566

General Routing

• OnTXP/TXP-3Dplatform, a bad I2Cdevice onSFCSwitch InterfaceBoard (SIB)might

cause Switch Processor Mezzanine Board (SPMB) to crash and all SIBs to be unable

to online. PR846679

• Changing the redundancymodeof rlsq interface from"hot-standby" to"warm-standby"

on the fly might lead to kernel crash and the router will go in db> prompt. PR880451

• A few particular sequence of member failures in an AMSwith HA-enabled and with

NAPT-44 configured can cause sessions to reset after a GRES (or SPD restart).

PR910802

• In scale DHCP subscribers scenario (e.g. 54K dual-stack DHCPv4/DHCPv6), graceful

Routing Engine switchover (GRES) is configured. If Routing Engine switchover occurs,

after that execute the command "root@user> show dynamic-configuration" many

times, large scale DHCP or DHCPv6 subscribers might be terminated. PR968021

• In the dual Routing Engines scenario with 8K PPP dual stack subscribers. In rare

condition, after Routing Engine switchover, some subscribers are stuck in terminating

state forever. PR974300

• 1)Due toaprevious fix chassisdon theprotocolmasterRoutingEngineand theprotocol

backup Routing Engine connect to the main snmpd on the protocol master using the

followingmethods. a) Chassisd on the protocolmaster Routing Engine connects using

a local socket since snmpd is running locally. b) Chassisd on the protocol backup

Routing Engine connects using a TNP socket since snmpd is not local. 2) However this










fix changed the way the other daemons connect to snmpd. All important daemons

runon theprotocolmaster andshould connect to snmpdusinga local socket.However

the fix changed it so that all daemons that ran on the protocol master (other than

chassisd) tried to connect using the TNP socket. SNMPD does not accept these

connections.Asa fix, inanMX-VC,wemadesure thatchassisdconnects toall processes

which run on the protocol master using internal socket while the chassisd process on

the protocol backup and protocol lincecard connect connect using TNP socket.

PR986009

• In 6PE scenario, when PE router is sending IPv6 TCP traffic to MPLS core, in rare

occasions, the kernel might crash and reboot with a vmcore file dumped. PR988418

• OpenFlow v1.0 running on an MX Series router does not respond reliably to interface

up or down events within a specified time interval. Per a fix implemented in Junos OS

Release 13.3R3.6, OpenFlow v1.0 running on an MX Series router responds reliably to


PR989308

• OnM7i/M10i with enchanced CFEB, M320 with E3-FPC, M120 and MXwith DPC. If

"no-local-switching" is present in the bridge domain, then the IGMP-snooping is not

functioning and client cannot see the multicast traffic. PR989755

• During large scale MVPN routes churn events, some core-facing IGP protocols (like

OSPF or LDP)might flap or experience a long convergence time. PR989787

• On T4000 router with type5 FPC. After FPC rebooting, if chassisd process does not

get FPC ready/FPConlineACKmessage fromFPC in 360 seconds, the FPCmight reset

again. PR998075

• OnM/MX/TSeries routers (platforms)withNetwork Address Port Translation (NAPT)

configuration.When the router receives the packet whose value of protocol field in the

IPv4 header is 61, the router erroneously does NAPT44 translation. In the correct

situation, the packet should not be translated and forwarded. PR999265

• Commit error needs to be reported when using unsupported NAPT44 nat-options

max-sessions-per-subscriber configuration with MS-MIC/MS-MPC. PR993320

• The PICmemory gauge counters show up as 0 after a GRES switchover in the "show

chassis pic fpc-slot X pic-slot Y" output. PR1000111

• OnMX240/MX480/MX960 routers running as precision time protocol (PTP)master

when interconnect with MX104 routers running as slave, the PTP clocking state might

get stuck in "INITIALIZING" for the first createdPTPport and not be aligned to clocking

state. Another issue is that when issue command "show ptp clock", wrong "slot"

number might be seen on MX104 slave. PR1001282

• "Syslog generated for session-open will have nat port information only if it is different

from the original source port". PR1001912

• If issue the command "show services nat mappings endpoint-independent" or "show

services nat mappings address-pooling-paired" or "show services sessions" and kill it

immediately when using EIM/APP feature with toomany EIM/APP entries present in

the system, lots of ipc message reply failure messages may be seen in the syslog.

PR1002683


Resolved Issues













• Multi-Services PIC could crash and restart on receiving a stray SIGQUIT signal due to

it not handling the signal. PR1004195

• When several PICs are set up as an aggregated Multi-services (AMS) doing

load-balancing, if one PIC of the AMS bundle gets offline and then gets online, 30 to

40 secondsmomentary traffic loss might be seen. PR1005665

• Ingress queuing is not supported on MPC5 (With Q-MPC) when Optical Transport

Network (OTN) is enabled. Enabling ingress queuing with OTNwould lead to line card

crash. PR1008569

• Withmore thaneight service-setsconfigured,whenusingSNMPmibwalk for service-set

(object "jnxSpSvcSetTable") info, the mspmand process (which manages the

Multi-Services PIC) might crash. PR1009138

• When the SIB plane state changed to fault state, it should read the FPGA for the power

related information instead of reading from the cpld. PR1009402

• Whenever an FPC goes down suddenly due to hardware failure, the data traffic in

transit towards this FPC fromtheother FPCs couldbe stuck in the fabric queue thereby

triggering fabric drops due to lack of buffers to transmit the data to active destination

FPCs. PR1009777

• On ALG router without "flow-control-options" configured, MS-MICmight not service

packets any more once prolonged flow control is hit and cleared. PR1009968


• When the GE port is configured withWAN PHYmode, a "Zero length TLV" message

might be reported from the port. This is a cosmetic issue. PR673937

• With nonstop active routing (NSR) enabled, the VRRP tracking routes state on backup

Routing Engine might not get synchronized when adding/deleting the tracking routes.

PR983608

• OnMX Series platform, when an aggregated Ethernet bundle participating as Layer2

interface within bridge-domain goes down, the following syslog messages could be

observed. Themessages would be associated with FPC0 even if there are no link(s)

from this FPC0 participating in the affected aggregate-ethernet bundle. mib2d[2782]:

SNMP_TRAP_LINK_DOWN: ifIndex 636, ifAdminStatus up(1), ifOperStatus down(2),

ifNamexe-3/3/2mib2d[2782]: SNMP_TRAP_LINK_DOWN: ifIndex637, ifAdminStatus

up(1), ifOperStatusdown(2), ifNamexe-3/3/3mib2d[2782]:SNMP_TRAP_LINK_DOWN:

ifIndex740, ifAdminStatusup(1), ifOperStatusdown(2), ifNameae102 fpc0LUCHIP(0)

Congestion Detected, Active Zones f:f:f:f:f:f:f:f:f:f:f:f:f:f:f:f fpc0 LUCHIP(0) Congestion

Detected, Active Zones 2:0:0:0:0:8:a:0:0:0:0:0:8:4:0:a alarmd[1600]: Alarm set: FPC

color=RED, class=CHASSIS, reason=FPC 0Major Errors craftd[1601]: Major alarm set,

FPC 0Major Errors fpc0 LUCHIP(0) Congestion Detected, Active Zones

2:0:0:0:0:8:a:0:0:0:0:0:8:4:0:a alarmd[1600]: Alarm cleared: FPC color=RED,

class=CHASSIS, reason=FPC 0Major Errors craftd[1601]: Major alarm cleared, FPC 0

Major Errors fpc0 LUCHIP(0): Secondary PPE 0 zone 1 timeout. fpc0 PPE Sync XTXN

Err Trap: Count 7095, PC 10, 0x0010: trap_nexthop_return fpc0 PPE Thread Timeout

Trap: Count 226, PC 34a, 0x034a: nh_ret_last fpc0 PPE PPE Stack Err Trap: Count 15,

PC 366, 0x0366: add_default_layer1_overhead fpc0 PPE PPE HW Fault Trap: Count












10, PC 3c9, 0x03c9: bm_label_save_label fpc0 LUCHIP(0) RMC 0 Uninitialized

EDMEM[0x3f38b5]Read(0x6db6db6d6db6db6d)fpc0LUCHIP(0)RMC1Uninitialized

EDMEM[0x394cdf] Read (0x6db6db6d6db6db6d) fpc0 LUCHIP(0) RMC 2

Uninitialized EDMEM[0x3d9565] Read (0x6db6db6d6db6db6d) fpc0 LUCHIP(0)

RMC3UninitializedEDMEM[0x3d81b6]Read(0x6db6db6d6db6db6d)Thesemessage

would be transient in nature. PR990023

• In the demux interfaces over aggregated Ethernet (AE) environment with

targeted-distribution configuration. The index of AE interface is confused when the

index ismore than 100. It copiesonly fourbytes from interfacename. (e.g. If binddemux

interface to ae110, it will be bound to ae11 at the same time). The traffic forwarding

might be affected. PR998906

• OnMX Series router with MX Series linecard or T4000 router with type5 FPC, when

the"Hardware-assisted-timestamping" isenabled, theMPCmodulesmightcrashwith

a core file generated. The core files could be seen by executing CLI command "show

system core-dumps". PR999392

• IGMP joins do not work for PPP subscribers that are usingMLPPP and LNS. PR1001214

• Fabric Blackholing logic recovery for certain cases will be done with different action

(Phase 1/2/3) based on the problem. PR1009502

• Here is the expected behavior for CFM CCM: 1. UP MEP CFM session a. If there is a

manually configured ieee-802.1 classifier attached to the interface, then forwarding

class of the CCM injected should match the respective classifier. b. If there interface

in which CFM is configured has no ieee-802.1 based 1p classified, then the forwarding

class of the CCMwill take as configured in "host-outbound-traffic". c. In case if there

is no "host-outbound-classifier"present thenpacketswill be treatedasnetworkcontrol

(Q3). 2. DownMEP CFM session a. forwarding class of the CCMwill always depends

on the FC classified based on "host-outbound-traffic". If it is not configured, then it

will always take Q3. PR1010929

J-Web

• An insufficient validation vulnerability in J-Web can allow an authenticated user to

execute arbitrary commands. This may allow a user with low privilege (such as read

only access) to get complete administrative access. This scope of this vulnerability is

limited to only those users with valid, authenticated login credentials. Please refer to

JSA10560 for more information. PR826518

Layer 2 Features

• In BGP signaled VPLS/VPWS scenario, rpd process memory leak might occur when

groups with wildcard configuration is applied to the routing instance. PR987727

• In BGP-VPLS scenarios with GRES activated, rpd process might crash in cycles after

manually restarting rpd. PR1011165

Layer 2 Ethernet Services

• When "system no-redirect" is configured, l2 descriptor destination MAC address gets

overwritten and causes "DA rejects" on next-hop router. PR989323


Resolved Issues











• In race condition, when FPC gets rebooted or reset, link(s) from this FPC which are

part of aggregatedEthernetbundlewould remain inLACP"Detached" state indefinitely.

user@router> show lacp interfaces ae102 Aggregated interface: ae102 LACP state:

Role Exp Def Dist Col Syn Aggr Timeout Activity xe-2/0/0 Actor No Yes No No No Yes

Fast Active xe-2/0/0 Partner No Yes No No No Yes Fast Passive xe-2/0/1 Actor No No

Yes Yes Yes Yes Fast Active xe-2/0/1 Partner No No Yes Yes Yes Yes Fast Active LACP

protocol: Receive State Transmit State Mux State xe-2/0/0 Defaulted Fast periodic

Detached xe-2/0/1 Current Fast periodic Collecting distributing user@node> show

interfaces xe-2/0/0 terse Interface Admin Link Proto Local Remote xe-2/0/0 up up

xe-2/0/0.0 up up aenet --> ae102.0 xe-2/0/0.32767 up up aenet --> ae102.32767 This

issue would be seen when associated aggregated Ethernet bundle is configured for

vlan-tagging. To clear this condition, the affected interface should be deactivated and

activated using CLI commands. user@node# deactivate interfaces xe-2/0/0

user@node#commit user@node#activate interfaces xe-2/0/0user@node#commit

PR998246

• In the Ethernet ring protection switching (ERPS) environment, once graceful Routing

Engine switchover (GRES) happens on the ring protection links (RPLs) owner node,

there will be a ~30s Ring automatic protection switching (R-APS)message storm in

the ring, which in turn causes some VPLS instance flapping. PR1004066

MPLS

• In the MPLS environment with no-cspf and strict ERO configuration. In race condition,

if a PATHmessage with routing loop error is received before standby Routing Engine

has resolved the correct PATHmessage with no loop, some of LSP are not replicated

on standby Routing Engine. If Routing Engine switchover occurs, the forwarding traffic

might be affected. PR986714

Network Management andMonitoring

• The Packet Forwarding Engine local protocol statistics are 32-bit counters. If there is

a rollover (typical candidates are arp/lacp), those counters start from zero. mib2d will

addall counters again if oneof thepfe statistics traffic counter is less then theprevious

collected counter, causing the multiplication affect. PR986712

• Alarmmanagement daemon runs onmaster and backup Routing Engines on dual

Routing Engine systems. There is a 80megabyte alarm.db file that is copied over from

masterRoutingEnginetobackupRoutingEnginewhenthealarm-managementdaemon

has come up on both the Routing Engines. The basic issue is that alarm-management

daemon is trying to copy the alarm.db file over and over again in an infinite loop on the

system, causing CPU utilization shooting up after every 20 seconds or so. PR988969


• The error message 'unlink(): failed to delete .perm file: No such file or directory' was

logged when disconnecting from a Telnet session to the router. PR876508

• The cprod commands essentially allow "root" access to FPCs. Therefore, access to

those commands should be highly restricted. The issue here is any user with "shell"

permissionwill beallowed tousecprodcommand.Weshouldadd restrictions to cprod

to only "root" permission users. PR924574










• The continuous executing of CLI mib walk commandmight cause user being unable

to issue showcommandsandenter configuremodewith error "Littlememory remains.

Command not stored in history." PR949735

• OnMX Series platform, MPCmight crash and reboot when a non-template filter gets

deleted (but does not get completely cleaned up) and the same filter index gets

reassigned toa template filter. This couldbeconsideredasa timing issuegiven it comes

with a very specific sequence of events only. PR949975

• When a port being used for port mirroring goes down due to an external factor, such

asa fiber cut or the remote side rebooting, theFPCCPUmay rise to 100%for4minutes

and then followedbya reboot of the FPCwith a reasonof "pfemanwatchdogexpired".

The issue will only be observed occasionally and requires that the FPC CPU is already

very busy and very large firewall filters (thousands of terms long) to be used. If any of

these three factors are not present, the issue will not occur. As such disabling the port

being used for portmirroring on the Juniper prior to bringing down that link is sufficient

to avoid this issue. PR968393

• OnMX Series based line card, VPLS traffic might get blocked for about 5 minutes

(timer of MAC address aged-out) after re-negotiating control-word. PR973222

• The problem is seen because CFMD is getting a configuration commit after theMX-VC

switch has happened. This commit is deleting the cfmd session and then creating a

new sessionwhich is causing the old information of action-profile to be deletedwhich

brings the interface back up. This problem is fixed by the code correction. PR974663

• OnMXVirtual Chassis platforms, if you configure the interfacealias feature, the feature

might not work as expected and interfaces might go up and down after commit.

PR981249

• HaveBFDsessionbetweenone router supporting inline-BFD (MXSeries and Junos 13.3

or higher) and the other which does not support inline-BFD (any version and non-MX

Series, or MX Series and Junos OS prior to 13.3). When the "failure detection time" is

less than 50ms, the BFD session might flap. PR982258

• OnMX2020/MX2010wemight see sporadic FO request time-out error reported under

heavy system traffic load. This would mean the request returning into a grant took

longer then +/-30usec. The packet will still get forwarded through the fabric hence no

operational impact. [May 6 18:56:59.174 LOG: Err] MQCHIP(2) FO Request time-out

error [May 6 19:33:47.555 LOG: Info] CMTFPC: Fabric request time out pfe 2 plane 6

pg 0, trying recovery PR991274

• Packets dropped with IPv6 reject route are currently subjected to loopback ipv6 filter

processing on MX Series-based line cards. As a result the packet dropped by a reject

route may be seen from the "show firewall log". PR994363

• On anMX Series router with MX Series linecard or T4000 router with type5.When the

firewall filter under the [forwarding-options] hierarchy within a bridge domain is

removed, it might result in lookup error and frame dropmight be observed. PR999083

• In the IRB interface environment with "destination-class-usage" configuration. If the

bridge domain ID is the same as Destination Class Usage (DCU) ID (bridge domain ID

and DCU ID are generated by system), the firewall filter might match wrong packets,

the packet forwarding would be affected. PR999649


Resolved Issues












• OnM7i, orM10i equippedwithEnhancedCompactForwardingEngineBoard (CFEB-E).

When a MPLS LSP flaps, the CFEB-E is unable to recover 8 bytes of JTREEmemory

per event. PR1000385

• MS PICmay reset after GRES in case of excessive resolve traffic. PR1001620

• When sending traffic comingonMPCandgoing out onDPC, theMACentry on aPacket

Forwarding Engine will not be up-to-date and the frames targeted to a knownMAC

address will be flooded across the bridge domain. PR1003525

• The non-first IP fragments containing UDP payloadmay bemistakenly interpreted as

PTP packets if the following conditions are met: - the byte at the offset 9 in the IP

packet contains 0x11 (decimal 17) - UDP payload - the two bytes at the offset 22 in the

IP packet contain the value 0x01 0x3f (decimal 319; byte 22=0x01 and byte 23=0x3f)

- PTP protocol Themis-identification of the packet as PTP will trigger the corruption

of the fragment payload. PR1006718

• WhenMicro-BFD configurations is added after the ae bundle configuration, then

micro-bfdsession for all themember links remains in "Down"state.Below is thesnippet

as reference, when ae100 LACP state is "Disturbing", while micro-BFD session remain

in "Down" state while on the other end the session would be in "Init" state.

user@ndoeA> show lacp interfaces ae100 Aggregated interface: ae100 LACP state:

Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/3/0 Actor No No Yes Yes Yes

Yes Fast Active xe-0/3/0 Partner No No Yes Yes Yes Yes Fast Active xe-0/3/1 Actor

No No Yes Yes Yes Yes Fast Active xe-0/3/1 Partner No No Yes Yes Yes Yes Fast Active

LACPprotocol: ReceiveStateTransmitStateMuxState xe-0/3/0Current Fast periodic

Collecting distributing xe-0/3/1 Current Fast periodic Collecting distributing

user@ndoeA> show bfd session address 10.10.100.145 Detect Transmit Address State

Interface Time Interval Multiplier 10.10.100.145 Down xe-0/3/0 0.000 1.000 3

10.10.100.145 Down xe-0/3/1 0.000 1.000 3 PR1006809

• Memoryallocated in reference to theBFDsessionwasnotgetting freedup.This resulted

in memory leak and thememory exhaustion triggered crash. PR1007432

Routing Protocols

• When the IPv6 address on fxp0 is active during bootup, the joining of the all-router

group causes the kernel to create a ff02::2 route with a private next-hop, which is not

pushed to the Packet Forwarding Engine. When a non-fxp0 interface is active later,

theprivatenext-hopwill be sharedby thenon-fxp0 interfaceaswell, resulting inpacket

drops destined to ff02::2 on the non-management interface. - After this PR, the

advertising interface should be configured via the following CLI. [edit protocols] +

router-advertisement { + interface <interface_name>; + } PR824998

• Performing CLI command "clear multicast bandwidth-admission interface <int>" on

64-bit Junos OS results the rpd process crash. The command should be used without

the interface qualifier on the impacted releases. PR949680

• There are two receivers joined to same (S,G) and IGMP immediate-leave is configured.

When one of the receivers sends the leavemessage for (S,G), another receiver is not

receiving the traffic for 1-2 minutes. PR979936












• In the P2MP environment with OSPF adjacency are established. One router's time is

set to earlier date than another router. OSPF adjacency might not come up when one

router goes down and comes up. PR991540

• Bringing up DFWD based BFD sessions at scale causes a churn in DFW as a result of

which the FPC CPU usage remains at 100% for a prolonged timespan. PR992990

• BMP is not sending a correctly formatted prefix for inet/inet6 labeled unicast BGP

family routes. This occurs if the route resides in the inet[6].0 table, and not if the route

resides in the inet[6].3 table. PR996374

• There are two scenarios that the rpdmight crash. The first scenario is when all BGP

peers flap with bgp route target proxy configured. The second scenario is when BGP

session is configured in a way that one side is configured with family l2vpn

auto-discovery-only, while on the other side is configured with both family l2vpn

signaling and keep all knobs. PR1002190

• When IS-IS is configured for traffic engineer (TE), after remove family mpls from the

interface and remove the specific interface from [edit protocols rsvp] and [edit

protocols mpls] hierarchy level, corresponding link is not removed from the TED as

expected. PR1003159

• When there are more than 65535 "flow-spec" routes existing in the routing table, the

rpd processmight crash because it exceeds the currentmaximumsupportable scaling

numbers (Current scaling numbers are in the range of 10K~16K). PR1004575

• During unified in-service software upgrade (ISSU), when a Bidirectional Forwarding

Detection (BFD) session negotiation is happening, if the session is configured with 10

seconds or higher interval, BFD session would flap. PR1010161

• MisconfiguringBGP routevalidationsession to the router itselfmight lead to rpdprocess

crash. PR1010216

• In scaled BFD scenarios, BFD unified ISSU poll negotiation will fail causing the BFD

session to flap during unified ISSU. PR1012859

• Multicast packets might get dropped with NSR configured and graceful switchover of

the Routing Engine is performed. PR1020459


• OnMX240/480/960 routers with MS-DPCwith "deterministic-port-block-allocation

block-size" configuration. In rarecondition,when the "block-size" is set toa larger value

(in this case, block-size=16128), the Services PICmight crash. PR994107

• jflow-logging: seen "mspmand.core.ms41.0.gz*" with data traffic. PR994256

• The redundant services PIC (rsp-) interfaces or redundant Multiservices (rms-)

interfaces configured with "hot-standby" modemight flap upon committing any

configuration change (will happen for evenanunrelated interfacedescription change).

PR1000591

• The following messages are being logged at ERR not DEBUG severity: mspd[3618]:

mspd: Nomember config mspd[3618]: mspd: Building package info This PR sets the

correct severity. PR1003640


Resolved Issues















Subscriber Access Management

• MIB entries for jnxUserAAAAccessPoolRoutingInstancemay not appear after deleting

and re-adding an assignement pool under a routing instance. PR998967

VPNs

• In theRosenMVPNenvironment, somedatawouldpass intermittently over thedefault

MDT even after hitting threshold to switch to data MDT. PR999019

• Serving site B is not receiving all the traffic from serving site A when traffic is reduced

from the exceeded cmcast limit. PR1001861



• We cannot bind classifier on GRE interface" for MX Series routers withMPCs andMICs

for some customer demand now. To restore the old behavior, we can configure

'exp-default' knob on GRE interface with the fixed Junos OS image. << example >>

set class-of-service interfaces gr-0/0/0 unit 0 classifiers exp default. PR941908

• If anyof the schedulers havean IDof zero, cosdprocessmight crash followingacommit.

PR953523

• Sometimes the cosd generate the coredumpwhen add/delete child interface on the

LAG bundle. PR961119

• Applying a scheduler with transmit rate below 65,535 bps and rate-limit option fails

the commit if the associated interface is an non-existing interface or a virtual interface.

PR964647

• OnMX Series router with non-Q DPC (in this case, DPCE 40x 1GE R), when the

"interface-set" is configured on a non-Q DPC, then execute the command "show

interfaces interface-setqueue<interface-set-name>", theDPCmightcrash. PR979668


• VPLSmac-tabledoesn't getspopulatedwithmacofprevious lt interfaceafter replacing

the lt interface in the configuration, that might cause CE connected to the lt interface

to get isolated. PR955314

• When port-mirroring or sampling is configured, if a lot of route updates are happening

in the system, the routing protocol convergence timemight be long and packets loss

might be observed. PR963060

• In the large scaledDHCPsubscribers setup (e.g. 54,000dual-stackDHCPsubscribers),

dynamic firewall daemon (dfwd)memory leak during DHCP subscribers login/logout.

PR967328

• DPC crashed after deactivate/activate [routing-instances TPIX bridge-domains IX

bridge-options]. PR983640


















General Routing

• The ingress family feature (uRPF) unicast Reverse Path Forwarding check execution

order was invalidated when (FBF) Filter Based Forwarding was enabled on MX Series

routers with MPCs or MICs. This solution repositions uRPF just prior to Filter Based

Forwaarding (FBF), so that both actions are compatible and applicable. This applies

to both IPv4 and IPv6. PR805599

• OnMX Series routers containing multiple Packet Forwarding Engines such as

MX240/MX480/MX960/MX2010/MX2020,witheitherMPC3EorMPC4Ecards(MPC3

Type 3 3D/MPC4E 3D 2CGE+8XGE/MPC4E 3D 32XGE), if multicast traffic or Layer 2

flood traffic enters the router via these MPC3E or MPC4E line cards, these line cards

mayexhibit a lockup, andoneormoreof their Packet ForwardingEngines corrupt traffic

towards the router fabric. PR931755

• In theMX-VCscenario, havechassis fabric redundancymodeset to increasedbandwidth

(root@user# set chassis fabric redundancy-mode increased-bandwidth). Then

configure the "offline-on-fabric-bandwidth-reduction" for any slot (root@user# set

chassis fpc<slot>offline-on-fabric-bandwidth-reduction). After that execute commit,

the commit check failed and chassisd crashed with core-dumps. PR932356

• Thisproblemoccurswhena largeamountof servicesandamsconfiguration is changed

in a single override operation. A workaround for this problem is to offline and online

the PIC during or after the configuration change. PR933674

• In Junos OS versions later than 11.2 where IFL localization is enabled, Routing Engine

mastership switchover could lead to IFL indexes inconsistency in Ichip FPCs when

graceful Routing Engine switchover (GRES) is configured. This inconsistency could

gradually lead to IFL index overlaps and traffic blackholing. PR940122

• When nonstop active routing (NSR) is configured and thememory utilization of rpd

process on the backup Routing Engine is high (1.4G or above), the rpd crash on backup

RoutingEnginemaybounce theBGPsessionson themasterRoutingEngine. PR942981

• Under particular scenarios, commit action might lead the Context-Identifier to be

ignored when OSPF protocol refresh its database. Then the PE router will stop

advertising this Context-Identifier out. PR954033

• FPCmight lose the socket connection to the Routing Engine during the time kernel

live-core dump is active. IGP session might get dropped after the socket connection

got closed.TheFPCwill get restartedby thekernel once the live-coredumphas finished.

PR954045

• Softwarewillmonitor the FPDdial setting in SFC and LCCand raise a alarm if changed

during runtime. In SFC the config dial and in LCCM/S dial will bemonitored. PR955319

• "show interfaces et-x/y/z extensive" will display MRU now. MRU can be configured at

"set interfaces et-x/y/z gigether-options mru" If MRU is not configured then it is

defaulted toMTU+8.MRUdisplayed fromtheCLIdoesnot include theCRC. PR958162

• To support controlwordonBGP-VPLS forM-320 (i-chip) andMX(DPC+MPC), below

2 config knobs are newly introduced. routing-instances { green { protocols { vpls { +

control-word; <<<<<<<<< new knob. + no-control-word; <<<<<<<< new knob. } } }

} To omit IP payload over ether-pw fromhash-key forMXSeries, A newknob like below


Resolved Issues












will be provided. forwarding-options { enhanced-hash-key { family mpls { +

no-ether-pseudowire; } } } PR958685

• In subscribermanagement environment, upgrade JunosOS to specific version (include

12.3R6 13.2R4 13.3R2) via ISSUmight make subsequence subscribers fail to connect

with following error: "jdhcpd_profile_request: Add Profile dhcp request failed for client

in state LOCAL_SERVER_STATE_WAIT_AUTH_REQ: error = 301". PR959828

• OnMXVirtual Chassis (MX-VC), if multiple VCP ports are configured betweenMPC5E

cards, traffic might not be load balanced over the VCP ports, besides, packets might

get lost due to VC ingress and egress next-hop caches getting out of synchronization.

PR960803

• Default threshold for ES-FPC errors is 1 for major errors and 10 for minor errors, when

the threshold is reached, someactions (eg, alarm|offline-pic|log|get-state|offline|reset)

will be taken by FPC as configured. This feature is designed for permament/real errors.

The issue here is that even some transient errors (eg, link flaps) will also trigger the

default action. In some cases, it might cause panic for the FPC. PR961165

• Ethernet over ATM LLC hasmissing OUI information. PR961468

• Onall JunosOSplatforms, if aneventoccurs that causes thePacket ForwardingEngine

to restart, service might be interrupted because the stale interface index has not been

deleted. PR962558

• In the initial router configuration, if static routes are configured over GRE interface and

OAM is enable, then the static routesmay remain active while the GRE tunnel is down.

PR966353

• NHtracingprovidesa lightweightmechanismtocaptureNHchains traversedbypackets

of interest for further examination. PR967450

• Support for layer 3 VPN localization has been deprecated in the JunosOS releases and

platforms listedbelow.This affects the followingCLI command: "set routing-instances

[instance-name] routing-options localize" Junos OS releases: - 12.3R7 (CLI command

is hidden) - 13.1R5 (CLI command is hidden) - 13.2R5 (CLI command is hidden) - 13.3R3

(CLI command is removed) - 14.1 (CLI command is removed) - 14.2 (CLI command is

removed) Platforms: - M 320 Series router - MX Series routers (all) - T Series routers

(all). PR967584

• OnMX Series platform, when the Channelized T1/E1 Circuit Emulation MIC

(MIC-3D-16CHE1-T1-CE) with non-enhanced queuing MPC1 or MPC2 is inserted, no

traffic is being forwarded out of the T1/E1 ports. PR967861

• Although receiving the flow specification (flowspec) routes with packet-length,

icmp-code or icmp-typematching rules from a BGP peer properly, the local firewall

filter in the Packet Forwarding Engines might not include these matching rules.

PR968125

• Autoheal denied reasonmay not be shown if CRC errors occurs on the same cable

from F13 side more than once in an autoheal window and subsequently error is seen

is again from LCC side. PR973783

















• In processing for fpc-resync and fab-liveness packets if error occurs while sending

packet we do not free the packet. This causes packets buffers to leak and eventually

the packet heap runs out of memory. PR973892

• You cannot configure an MTU value on family inet greater than 1496 if there is a trunk

port configured on the interface; if you configure an MTU greater than 1496, a commit

error occurs. If you configure an MTU value on a physical interface on which a trunk

interface is configured, the configuredMTUvalue is ignored and the value is set to 1518.

These issues do not occur if there is no trunk port on the interface. PR974809

• PPP over ATM transit traffic was not being fragmented correctly by ATMMIC. The

changes allow the fragmentation of the transit traffic to work properly. PR976508

• Changing service-set configuration continuously during scaled traffic conditions may

result in mspmand process crash and a core file generated. PR978032

• On T Series router with FIB Localization enabled, if reboot the Routing Engine while

scaled traffic running, the FIB-remote FPCmight crash. PR979098

• In the high scale P2MP LSP environment, heapmemory leak might occur when the

LSP flaps. Then some P2MP LSPsmight be not installed, so the traffic will lose.

PR979211

• scale-subscriber "License Used" filed shows wrong value after GRES. PR980399

• In rare condition, when PPPoE subscribers login with large amounts of configuration

data, the subscriber management infrastructure daemon (smid) and authentication

service process (authd) might crash, and no new subscribers could connect to the

router. PR980646

• In the BFD environment with static route, the BFD session is established between two

routers.When disable the subinterface on one router, the BFD AdminDown packet will

be sent out from the router (this is not expected). But according to RFC 5882, another

router receives theAdminDownpacket, the static routewill never bedeleted on it. That

might cause traffic packets to be dropped. PR982588

• In scenarioofNG-MVPNwithP2MPLSPasprovider tunnel,KernelRoutingTable (KRT)

might get stuck after making changes for MVPN, then traffic loss will be seen, and

besides, rpd processmight crash while trying to generate a live core dump. PR982959

• With a firewall policer configured onmore than 256 IFFs (interface address family) of

a PIC, then offline and online the PICmight cause the FPC to crash. PR983999

• OpenSSL library in Junos OSwas patched to resolve CVE-2010-5298. PR984416

• OnM7i/M10i with enchanced CFEB, M320 with E3-FPC, M120 and MXwith DPC. In a

race condition, the Dense Port Concentrator (DPC)may crash when ifls get added to

an ifl-set while that same ifl-set get deactivated/deleted in class-of-service. For

example:#set interfaces interface-set interface_set_JTAC_ge-3/0/0 interfacege-3/0/0

unit 100 # deactivate class-of-service interfaces interface-set

interface_set_JTAC_ge-3/0/0 # commit or (quick commit of following changes) # set

interfaces interface-set interface_set_JTAC_ge-3/0/0 interface ge-3/0/0 # commit

# deactivate class-of-service interfaces interface-set interface_set_JTAC_ge-3/0/0

# commit. PR985974


Resolved Issues















• OpenFlow does not respond to port_down events when the echo interval timeout is

set for less than 11 seconds. PR989308

• The fabric performance ofMPC1, MPC2, or 16xXEMPC in 'increased-bandwidth'mode

on an MX960 populated with SCBE's will be less compared to redundant mode due

to XF1 ASIC scheduling bugs. PR993787

• Under normal circumstances, the Maximum Receive Unit (MRU) value is set to MTU

size + 8 bytes (e.g. MTU=9102, MRU=9102+8=9110). But in this case, whenMTU is set

to a large value (MTU=9192) on AE interface, theMRU still uses the default value 1522

bytes. Sowhen the interface receives packetswhich size aremore than 1522 bytes, the

packets are dropped. PR994826

• On10X10GESFPP,whenan interfaceconfigured forCCCandasynchronous-notification,

and it is told to turn off its laser. Its laser flaps on and off for some period of time.

PR996277

• On T4000 router with type5 FPC. After FPC rebooting, if chassisd process does not

get FPC ready/FPConlineACKmessage fromFPC in 360 seconds, the FPCmight reset

again. PR998075

• When using AMS load-balancing if a PIC in the AMS bundled if offline for any reason

and the operator on-lines the pic there is slight 30 to 40 secondmomentary traffic

loss. PR1005665

• The PICmemory gauge counters show up as 0 after a GRES switchover in the "show

chassis pic fpc-slot X pic-slot Y" output. PR1000111

• ServicePIConMS-MPCcardcouldcore-dumpand restart on receivingastraySIGQUIT

signal due to it not handling the signal.With this fixwe ignoreSIGQUIT signal andavoid

Service PIC restart. PR1004195

Infrastructure

• OnRE-S-1800familyofRoutingEngine, afteran intensivewriting toSSD, the immediate

rebooting might cause SSD to corrupt. PR937774


• If the "tunnel-destination"addressofaGenericRoutingEncapsulation (GRE) interface

is placed in one instance and the GRE interface is placed in another routing-instance,

the lookup for the GRE tunnel destination is done on inet.0 instead of the appropriate

routing instance's inet.0 table. The similar issue could happen on IP-over-IP or

Automatic Multicast Tunneling (AMT) tunnels too. PR851165

• NPC crash seen while verifying Inline Jflow in both RE0 and RE1 and do switchover 10

times and verify new files are updated properly. This is software bug which have been

fixed in 12.3R5. PR905916

• The Packet Forwarding Engine alarms raised by PFEMAN thread using cmalarm api

calls will not be transmitted to Routing Engine. As impact, these alarmswill not reflect

on Routing Engine. There is no impact on functionality, otherwise. PR921254

• If offline and remove a Non-Ethernet Modular Interface Card (MIC) fromMX Series

and then perform a unified in-service-software-upgrade (ISSU), the unified ISSUmay
















get aborted. This happens because although theMIC is removed physically but it does

not get removed from the hardware database (HWDB), which makes the chassis

mistakenly try to offline the already removedMICduring unified ISSUand in turn cause

the upgrade failure. PR923569

• Queue stats counters for AE interface will become invalid after deactivating ifl on the

AE interface. PR926617

• Strange FRU Insertion trap[RE PCMCIA card 0] is generated when Routing Engine

master-switching is done on box with RE-1800. PR943767

• Kernel crash might happen when a router running a Junos OS install with the fix to PR

937774 is rebooted. This problemwill not be observed during the upgrade to this Junos

OS install. It occurs late enough in the shutdown procedure that it shouldn't interfere

with normal operation. PR956691

• When an ifl containing some vrrp group configuration is deleted, snmpwalk on vrrp

MIBmay loop continuously. PR957975

• If there is an IRB interface configured for "family inet6" in a bridge-domain on an MX

Series router, the Packet Forwarding Engine may not correctly update the next-hop

for an IPv6 route when theMAC address associatedwith the next-hopmoves from an

AE interface to a non-AE interface. PR958019

• In very uncommon situation, we will see LCCs chassisd state is inconsistent with SFC

chassisd state, this is verymisleading in troubleshooting stage. This PR fixed this issue.

PR963342

• Link speed of a LAG bundle may not properly reflect the total bandwidth, when

microBFD is enabled on the LAG interface. PR967046

• Temperature Top and Bottom are swapped in show chassis environments output for

Type3/Type4 FPCs of T Series. PR975758

• In the large scaled VPLS environment , during delete routing-instance of type VPLS,

thememory is not getting freed. The connectivity-fault management daemon (cfmd)

might crash with a core file generated.The core files could be seen by executing CLI

command "show system core-dumps". PR975858

• Vrrpdmemory leaksonlyonbackupRoutingEnginewithoutanyoperationoncondition

that graceful-switchover under chassis/redundancy is enabled and nonstop-routing

under routing-options is disabled with configuring ipv6 vrrp groups. PR978057

• In the multilink frame relay (mlfr) environment with "disable-tx" configuration. When

the differential delay exceeds the red limit, the transmission is disabled on the bundle

link. When it is restored, the link should be added back. But in this case, the link stays

disable state and it is not rejoined to the bundle. PR978855

• After the following process, we can findMCAEbecomes standby/standby status. Even

if we set "set interfaces aeX aggregated-ether-optionsmc-ae events iccp-peer-down

prefer-status-control-active" for both routers, we can find this issue. << topology

example >> iccp ge-1/0/1 ge-1/0/1 [ MX80(router A)]-----------------[MX240(router

B)] \ ae0 ae0 / --active-- \ / --standby-- \ MC-LAG / \ / \ / ae0(ge-0/0/0)\

/ae0(ge-0/0/1) [ EX4200(switch C) ] << process >> initial status router A : active

router B : standby 1. disable ae0 of router A. 2. disable iccp link of router A. 3. disable


Resolved Issues














ae0 of switch C 4. enable iccp link of router A. (Please wait until iccp status up.) 5.

enable ae0 of switch C 6. enable ae0 of router A. PR982713

• When upgrading to 13.3R2, customermay see the followingmessages: Chassis control

process: rtslib: ERROR kernel does not support all messages: expected 104 got 103,a

reboot or software upgrademay be required Chassis control process: Chassis control

process: rtslib: WARNING version mismatch for msgmacsec (103): expected 99 got

191,a reboot or software upgrademay be required Chassis control process: Chassis

control process: rtslib: ERROR kernel does not support allmessages: expected 104 got

103,a reboot or software upgrademay be required Chassis control process: Chassis

control process: rtslib: WARNING version mismatch for msgmacsec (103): expected

99got 191,a rebootor softwareupgrademaybe requiredThesemessagesaregenerated

during validating the new chassis management daemon against the old kernel, and

are harmless. PR983735

• 1GbE SFP(EX-SFP-1FE-LX) output optical power is restored after reseating bymanual

removal/insert of SFP although the IF is disabled. PR984192

• SNMPOID VRRP-MIB::vrrpAssoIpAddrRowStatus returns only one Ip address when

the interface ifl has configured with two virtual-addressees under two vrrp-groups.

PR987992

• Followingmessages couldbe seenon the router for the FPCslotwhich are evenempty.

These messages are cosmetic and could be ignored. chassisd[1637]: %DAEMON-6:

FPC 0 does not support Pic power off config cmd ignoring the config change

chassisd[1637]: %DAEMON-6: FPC 2 does not support Pic power off config cmd

ignoring the config change. PR988987

• CFMDmay crash after configuration change of an interface in a logical systemwhich

is under OAM config for a l2vpn instance. PR991122

Layer 2 Features

• WhenDHCP local server andDHCPrelayarebothconfiguredonsame router, theDHCP

relaybindingmightget lost if agracefulRoutingEngine switchover (GRES) isperformed.

PR940111

• In L3Wholesale environment, the DHCP clients might fail to renew their address in

DHCP relay scenario. PR956675

• Configuring Ethernet Ring Protection Switching (ERPS), after changing interface's

MTUonRing Protection Link (RPL) owner, all the interfaces on RPL owner change into

forwarding state, hence cause a layer 2 loop. PR964727

• OnMXSeries platformwith Ethernet Ring Protection Switching (ERPS) configuration,

after disabled Ring Protection Link (RPL) interface and thenmove RPL fromwest

interface to east interface, as a result, the ERPS east and west interface might go into

discard state at same time. PR970121

• In DHCPv6 subscriber environment, changing the c-tags (inner vlan)without clear the

DHCPv6 clients first is not recommended, it might cause the subscriber to use the old

inner vlan even after DHCPv6 RENEW process. PR970451
















• When Cisco running in an old version of PVST+, it does not carry VLAN ID in the end of

BPDU. So Juniper Networks equipment fails to responds to Topology Change

Notification ACK packet when it interoperates with Cisco equipment. After the fix,

Juniper equipmentwill read theVLAN ID information fromEthernet header. PR984563

• Layer 2 Control Protocol process (l2cpd) is used to enable features such as Layer 2

protocol tunneling or nonstop bridging. If a router receives a Link Layer Discovery

Protocol (LLDP) packets withmultiplemanagement address TLV,memory leakmight

occur which resulting in l2cpd process crash. PR986716

• jnxLacpTimeOut trapmayshownegative valuesand incorrect values for jnxLacpifIndex

and jnxLacpAggregateifIndex. PR994725

• In race condition, when FPC gets rebooted or reset, link(s) from this FPC which are

part of aggregate-ethernetbundlewould remain in LACP"Detached" state indefinitely.

user@node> show lacp interfaces ae102Aggregated interface: ae102 LACPstate: Role

Exp Def Dist Col Syn Aggr Timeout Activity xe-2/0/0 Actor No Yes No No No Yes Fast

Active xe-2/0/0 Partner No Yes No No No Yes Fast Passive xe-2/0/1 Actor No No Yes

Yes Yes Yes Fast Active xe-2/0/1 Partner No No Yes Yes Yes Yes Fast Active LACP

protocol: Receive State Transmit State Mux State xe-2/0/0 Defaulted Fast periodic

Detached xe-2/0/1 Current Fast periodic Collecting distributing user@node> show

interfaces xe-2/0/0 terse Interface Admin Link Proto Local Remote xe-2/0/0 up up

xe-2/0/0.0 up up aenet --> ae102.0 xe-2/0/0.32767 up up aenet --> ae102.32767 This

issue would be seen when associated aggregate-ethernet bundle is configured for

vlan-tagging. To clear this condition, the affected interface should be deactivated and

activated using cli commands. ============ [edit] user@node# deactivate

interfaces xe-2/0/0[edit] user@node#commit [edit] user@node#activate interfaces

xe-2/0/0 [edit] user@node# commit ============ PR998246

MPLS

• When the install prefix (specifiedby the "install" knob)anddestinationprefix (specified

by the "to" address of the LSP) are same for a static LSP, the routing protocol process

(rpd) might crash while deleting the LSP. PR958005

• During SNMPwalk on tableMPLS cross-connect table (mplsXCTable) in case of flood

nexthop, the rpdmight crash. PR964600

• In the large scaled MPLS setup with NSR enabled. When restart routing protocol

daemon (rpd) on standby Routing Engine, or reload standby Routing Engine, or reload

router, some filtered output label bindings might bemissed on the backup Routing

Engine,which leads toLabelDistributionProtocol (LDP)databasebetween themaster

and backup Routing Engines are inconsistent. PR970816

• In a scaled MPLS environment, whenever fast reroute (FRR) or Link Protection (LP)

or Node Protection (NP) is configured, the switchover from the primary LSP to the

secondary LSPmight cause traffic loss for few seconds. PR973070

• In the MPLS environment, when execute the command "show snmpmib walk

mplsXCTable" to walk the MPLS cross connect table, the routing protocol daemon

(rpd) CPU utilization might reach over 90%, and the rpd process doesn't respond to

any CLI show commands. PR978381


Resolved Issues










• snmpwalk/snmpgetnextor "showsnmpmibwalk" failwhenpollingMPLSLSPOCTETS,

MPLSLSPPACKETS, MPLSLSPINFOOCTETS or MPLSLSPINFOPACKETS. PR981061

• LSPmetricmodification leads to Constrained Shortest Path First(CSPF) computation

and resignaling. It should update RSVP routes directly. PR985099

• In the MPLS environment with "egress-protection" configuration, there is a direct LDP

session between primary PE and protector. One context-id is configured as primary

PE's loopback address or any LDP enabled interface address. When delete the whole

apply-group or delete the ldp policy from apply-group, the routing protocol daemon

(rpd) might crash. PR988775

• In the virtual private LAN service (VPLS) environment with multihoming (FEC 129) is

configured, when the router receives the label request for the Forwarding Equivalency

Class (FEC) 129, if there is no route for the specific FEC 129, the routingprotocol daemon

might crash. PR992983


• Alarmmanagement daemon runs onmaster and backup Routing Engine on dual

Routing Engine systems. There is a 80megabyte alarm.db file that is copied over from

masterRoutingEnginetobackupRoutingEnginewhenthealarm-managementdaemon

has come up on both the Routing Engines. The basic issue is that alarm-management

daemon is trying to copy the alarm.db file over and over again in an infinite loop on the

system, causing CPU utilization to shoot up after every 20 seconds or so. PR988969

OpenFlow

• OpenFlow v1.0 running on an MX Series router does not respond reliably to interface

up or down events within a specified time interval. Per a fix implemented in Junos OS

Release 13.3R3.6, OpenFlow v1.0 running on an MX Series router responds reliably to


PR989308


• Since theACPowerSystemonMX2020 isaN+Nfeed redundantandN+1power supply

modules (PSMs) redundant, there are two separate input stages per PSM , each

connected to one of the two different/redundant feeds. However, only one stage is

active at a time. This means, the other input stage (unused input stage) may be bad

and systemwill not know about it till it tries to switch to it in case of a feed failure.

PR832434

• When using OSPF/OSPFv3 with interface type point-to-point, it is possible that the

OSPFsession(usingmulticast traffic exclusively) tocomeupbeforenext-hop resolution

is done (ARP, or ND). In this case, transit traffic will be discarded, until resolution is

done. When you havemultiple links available, then the route will be balanced using a

"unilist" next-hop.When one of the links in the "unilist" doesn’t have layer2 resolution,

these next-hopswill actually drop traffic. The fix added by this PRwill make unilist not

contain forwarding and non-forwarding at the same time.When theNH resolutionwill

be done, then the link will be added to the unilist. PR832974












• The error message 'unlink(): failed to delete .perm file: No such file or directory' was

logged when disconnecting from a Telnet session to the router. PR876508

• When the instance have vlan-id all and adding interface unit with "vlan-tags outer X

innerY" to this instance, traffic fromALL instanceVLANs is leakingover that unit tagged

with outer tag X and each VLANs own inner tag A,B.C,..... Fix: When the instance have

vlan-id all, for dual tagged ifl the inner vlan check will be done. PR883760

• OnMX Series based line card, for interfaces tagged with VLAN ID same as the

native-vlan-id configured on the interface, FPC adds Native VLAN ID to the packets

received on the interface and destined to the host. This is irrespective of the packet

content. This results in the packets getting doubly tagged when receiving packets

which are already tagged with VLAN IDmatching the Native VLAN ID, and thus cause

ARP resolution failure on Native VLAN. For example, the ARP packets to IRB (on VLAN

101) are tagged with VLAN ID 101 (which is also the native VLAN ID) and are getting

additional tagged. Hence they are dropped by the IRB and this can cause the ARP

request packet not getting resolved on Native VLAN. PR917576

• When the transit traffic is hitting the router and the destination is a local segment IP

which requires ARP resolution, it's mis-classified by the DDOS filter and an incorrect

policer is applied. This leads to host queue congestion. PR924807

• Starting with Junos 13.3 and later, the range of cli screen-with is 40 through 1024 (in

earlier Junos OS releases, the range is 0 through 1024). This PR restores the option of

setting screen-width to 0 resulting in unlimited screen width. PR936460

• The Routing Engine and FPCs are connectedwith an internal Ethernet switch. In some

rare case, the FPCsmight receive amalformed packet from the Routing Engine (e.g.

packet gets corrupted somewhere on its way from Routing Engine to FPC). Then the

toxic traffic might crash the FPC. PR938578

• MPC Type 2 3Dmay crash with CPU hog due to excessive link flaps causing the

interrupts to go high. PR938956

• On a router which does a MPLS label POP operation (penultimate hop router for

example) if the resulting packet (IPv4 or IPv6) is corrupted then it will be dropped.

PR943382

• If a PE router is both egress and trazit node for a p2mp lsp, the Packet Forwarding

Engine may report errors and install a discard state for the fib entry representing the

p2mp lsp label with bottom of stack bit set to 0 . This problem does not have any

impact since there is no application using the s=0 entry of a p2mp lsp. PR950575

• * MX2020 FanTray power specification. - zone#1:FT#3 - gets power from zone#1 only

- zone#1:FT#2 - gets power from zone#0 in case of no-power in zone#1 - zone#0:FT#1

- gets power from zone#0 only - zone#0:FT#0 - gets power from zone#1 in case of

no-power in zone#0 - Critical(Minimum) number for MX2020 operation is 3 If one of

zone has no PSM, then it means FAN single-fault in the chassis's point of view. For

example, if zone#1 has noPSM, then the FT#3doesn't get power as it is local-powered

FT. Hence, in this case, the FT#3-LED should showORANGE to notify the single-fault

to user,while FT#2 can showsGREEN if it gets enoughpower fromzone#0. In addition,

CRAFT-LED for FT#3 should be turned off. * Due to HW-limit(bicolor), it could not

showORANGE color. In current implementation, both CRAFT-LED, FT#3-LED show


Resolved Issues











GREEN. That's problem. * NOTE: Junos OS doesn't support FT double-fault scenario.

(MX2020 needsminimum 3 FTs.) If FT#2 gets in trouble in above case(i.e.,FT

double-fault), the user should see serious cooling-trouble on SFMs within 1 minute.

PR957395

• Unable to modify dynamic configuration database after first commit. PR959450

• When we set "traffic-manager mode ingress-and-egress" on "MIC-3D-40GE-TX (3D

40x 1GE(LAN)RJ45)",we cannot use ingress queue correctly onPIC2 andPIC3. *Note:

We cannot see this issue if we set the above configuration to PIC0 or PIC1. PR959915

• Certain combinations of Junos OS CLI commands and arguments have been found to

be exploitable in a way that can allow root access to the operating system. This may

allow any user with permissions to run these CLI commands the ability to achieve

elevated privileges and gain complete control of the device. Refer to JSA10634 for

more information. PR965762











• A defect in L3VPNMake Before Break code was resulting in freeing memory

corresponding tooldnexthopswhich isbeingusedbyegressPacket ForwardingEngine.

This was resulting in memory corruption. PR971821

• WithNG-MVPN,multicast trafficmight get duplicatedand/or blackholed if aPE router,

with active local receivers, is also a transit node and the p2mp lsp is branched down

over an aggregate interface with members on different Packet Forwarding Engines.

PR973938

• SNMP alarms/traps could be generated for unpowered fan trays when only one zone

is powered. PR982970

• OnMX Series platform, when filter is applied on the interface with the action of "then

next-interface", thepackets that are forwardedby the firewall filterwouldbecorrupted.

PR986555

• Interface aliaswas not shown in the show commandswhen configured. Now interface

aliaswill be shown (IF CONFIGURED) in show commands containing interface names.

A |display no-interface-alias command adds the ability to show the actual interface

name if its needed. PR988245

• When services packet(interface-style) is diverted to different routing-instance using

a firewall filter, route lookup of the services packet wasmatching a reject route which

results in PPE thread timeout. PR988553


















• TXPwith 13.1R4might not trigger autoheal after65535CRCerror eventon inter-chassis

optical hsl2 link. Customer will need to domanual fabric plane reset to recover the

faulty SIBs after the 65535 CRC error event. PR988886

• NPC core /../src/pfe/ukern/cpu-ppc/ppc603e_panic.c:68. PR989240

• On logical-systems, backup rpd of logical systems is not getting SIGHUPwhen the

"commit fast-synchronize" statement at the [edit system] hierarchy level is enabled.

It causes the issue "restarting backup rpd" of logical systems (as part of recovery

mechanism). PR990347

• Whentwomidplane linkerrorsarepresentbetweenF13andF2Sibs thenCLOSrerouting

logic does not work properly. This can introduce RODR packet drops and result in

destination errors in the plane. PR992677

• "delete" or "deactivate" of apply-group defining the entire TACACS or RADIUS

configuration configured under [edit system apply-group <>] does not take effect on

commit. This could lead to TACACS or RADIUS based authentication to still continue

working despite removal (delete/deactivate) of configuration. PR992837

• OnMX Series router with MPCs or MICs or T4000 router with type5 FPC, if the CoS

scheduler is configured without transmit-rate while with buffer-size temporal, the

Packet Forwarding Engine might not allocate buffer for the associated queue. The

issue might lead to packets loss. PR999029

• The configuration to be applied to the feature auto backup Routing Engine upgrade

for NON-GRES case when back up Routing Engine has unsupported CB. policy

FRU-UNSUPPORTED { events CHASSISD_FRU_UNSUPPORTED; attributes-match {

CHASSISD_FRU_UNSUPPORTED.fru-namematches CB; } then { event-script

auto-image-upgrade.slax; } } event-script { file auto-image-upgrade.slax; }

Recommended setting: -------------------- Since above

CHASSISD_FRU_UNSUPPORTED event generated for every 20mins on box after boot

up, to stop from repetitive execution of this event policy, we can specify following

'within clause' in the event policy configuration. policy FRU-UNSUPPORTED { events

CHASSISD_FRU_UNSUPPORTED; within 1200 { not events

CHASSISD_FRU_UNSUPPORTED; } attributes-match {

CHASSISD_FRU_UNSUPPORTED.fru-namematches CB; } then { event-script

auto-image-upgrade.slax; } } event-script { file auto-image-upgrade.slax; }PR1000476

Routing Protocols

• InPIM-SMnetworkwith"bootstrap routing"RPselectionmechanismused, it isobserved

that some bootstrapmessages (BSMs) generation and forwarding behavior of Junos

OS does not conform to RFC standard, specifically in the section 3.2 (Bootstrap

message generation), 3.3 (Sending Candidate-RP-Advertisement Messages) and 3.4

(Creating the RP-Set at the BSR). PR871678

• In Protocol Independent Multicast (PIM) scenario, if interface get deleted before the

(S,G) route is installed in the Routing Information Base (RIB), then this interface index

mightbe re-usedbykernel foranother interfaceand thuscause routingprotocolprocess

(rpd) core. PR913706


Resolved Issues










• The rpd process might crash when executing the command "show route

advertising-protocol bgp <nbr>" without a table option, or with a table that is not

advertised by BGP. PR959535

• In the scenario of multicast receiver could receive traffic frommLDP or PIM, if at first

the multicast traffic is flowing over PIM, then the flapping of PIM protocol will cause

the traffic to flow over mLDP and later switch back to PIM, but the mLDP

forwarding-cachemight not get pruned, which resulting duplicated traffic. PR963031

• In certain rare circumstances, BGP NSR replication to the backup Routing Engine may

not make forward progress. This was due to an issue where an internal buffer was not

correctly cleared in rare circumstances when the backup Routing Engine was

experiencing high CPU. PR975012

• In scaledBGPenvironment, if anNSRenabled routerdoesnothaveany routing-instance

configured, after flapping BGP groupswithmultiple peers, some BGP neighborsmight

get stuck in 'not advertising' state. PR978183

• In the dual Routing Engine scenario, after an Routing Engine switchover, the periodic

packet management daemon (ppmd)might exit. PR979541

• OnMXSeries platformswith IGMP snooping enabled on an IRB interface, some transit

TCP packets may be wrongly considered as IGMP packets, causing packets to be

dropped. PR979671

• Due to some corner cases, certain commits could cause the input and/or output BGP

policies to be reexamined causing an increase in rpd CPU utilization PR979971

• PPMD filter is not programmed properly which is resulting Routing Engine to absorb

BFD packets instead of Packet Forwarding Engine. PR985035

• In Junos OS, by default the RIP protocol "send" option is set to Multicast RIPv2. When

this "send"option is changed from"multicast"(active) to "none"(passive)or vice-versa,

rpd core might be seen on the router. PR986444

• In V4 RG, member site receives traffic from both serving sites for few sources upon

withdraw/inject routes for 30 seconds. PR988561

• OSPF adjacency is not coming up with error "OSPF packet ignored: authentication

failure (sequence error)" in p2mpwhen remote peer goes down. PR991540


• Any SIP MESSAGE request will be dropped by the SIP ALG, this type of request is

unsupported from day one. This is rare type of request which will not prevent more

usual SIP operations such as voice calls, but it may affect some instant messaging

applications based on SIP. PR881813

• Clearing the stateful firewall subscriber analysis causes the active subscriber count to

displaya very hugenumber. The largenumber is seenbecausewhenasubscriber times

out the number of active subscribers is decremented. If it is set to zero using the clear

command, then a decrement would give an incorrect result. There is no impact to the

overall functionality and the fix is expected to be present in 14.1R2. PR939832

• Ping failure from LNS to MLPPP client. PR952708

















• The dynamic flow control process (dfcd) might core dumpwhen Dynamic Tasking

Control Protocol (DTCP) trigger request is same for both the VLAN and DHCP

subscriber. PR962810

• Message type for if_msg_ifl_channel_delete should be lower severity and not an error.

PR965298

• In the context ofDS-Lite softwire scenario,where theAddress Family TransitionRouter

(AFTR) node performs NATwith Endpoint Independent Filtering (EIF) and Endpoint

Independent Mapping (EIM) enabled, the simultaneous arrival of two packets from

opposite sides of the NATwill trigger the creation of the same flow, which in a race

condition results in the Service-PIC restart. PR966255

• During the Junos OS enhancement of the Port Control Protocol a few issues were

identified regarding NAT flows creation, clearing of the mappings, releasing the

addresses in use, etc. PR967971

• In the L2TP scenario with dual Routing Engines. After subscriber management

infrastructuredaemon(smid)being restarted,because thedeletenotification tobackup

Routing Engine might be lost, the subscriber database (SDB) information does not

synchronizebetweenmasterRoutingEngineandstandbyRoutingEngine.AfterRouting

Engine switchover is executed, the Layer 2 Tunneling Protocol daemon (jl2tpd) might

crash, and new L2TP subscribers are unable to dial. PR968947

• When transferring large FTP file, the server might send packets with incorrect layer 4

checksum. If inline NAT service is enabled on the router, it might transit the packets to

client insteadofdropping it,whicheventually causes theclient FTP timeout. PR972402

• If a PPPoE/PPP user disconnects in the access networkwithout the LAC/LNS noticing

it to tear down the connection (also the PPP keepalive hasn't detected yet), and a

second PPP request comes from the same subscriber on the L2TP tunnel (same or

different LAC/tunnel), then a second route is added to the table having the next hop

"service to unknown". PR981488

• The cflow export would cease due to memory exhaustion when flow-monitoring is

enabled using Adaptive Services II PIC due to memory leak condition. While in this

condition, user would see increments in "Packet dropped (nomemory)" as below:

user@node> show services accounting errors Service Accounting interface: sp-3/0/0,

Local interface index: 320Servicename: (default sampling) Interface state:Accounting

Error information Packets dropped (nomemory): 315805425, Packets dropped (not

IP): 0. PR982160

• In H323 ALGwith CGNAT scenario, the MS-PICmight crash when the ALG is deleting

an H323 conversation due to the deleting port is outside of allocated NAT port-block

range. PR982780

• OnM/MX/T Series routers (platforms) with Services PIC with dynamic-nat44

translation-type configured, when the flows are cleared the IP addresses in use are

never freed. This issue is present in JunOS 11.4R7 and all more recent releases without

this fix. PR986974

• In large scale L2TP LNS environment. When the SNMPMIB JNX-L2TP-MIB is walked

continuously, thememory of the L2TPdaemon (jl2tpd) increases due tomemory leak.

PR987678


Resolved Issues















• Routing Engine could be brought to DBmode when rebooting after interrupted

downgrade. PR966462

• By upgrade-with-config, user can specify a configuration to be applied on upgrade,

but the configuration filewill not be loadedpost upgrading. As a result, routerwill bring

up with old configuration. PR983291


• In early Release 13.3 code, if NSR and 64-bit rpd are used, there is a chance that the

Routing Engine may lose the primary floating IP address assigned to both Routing

Engine after a couple of GRES Routing Engine switchovers. This issue had been

corrected in later Release 13.3 branch codes. PR973278


• When load large scale configuration, due to the ddl object not being freed properly

after it's accessed, load configuration failed with error: Out of object identifiers.

PR985324

VPNs

• Upon withdraw /inject bgp routes in the serving PEs for two different

route-groups,member/regular sites receive traffic from both serving sites for 60

seconds. PR973623

• Route groupmember site and regular site may receive data from two serving sites of

twogroups for the same(S,G). This only happenswhen inoneRGthereareno receivers.

PR974245

• In Rosen MVPN environment, if there a twomultihomed ingress PEs, when the route

to multicast source flaps, the receiver router might keep switching between sender

Data MDTs, which resulting in traffic loss. PR974914

• In the Rosen MVPN environment, setting the TOS IP control packet bit can avoid the

possibility of data-mdt TLVmessages being dropped in the core during congestion.

But in this case, the TOS field to indicate its IP control packet (0xc0) is not set. This

might lead to traffic loss. PR981523

• The S-PMSI tunnelmight fail to be originated from ingress PE after flapping the routes

to customer multicast source. PR983410

• In MVPN scenario, a multihomed ingress PEmight fail to advertise type-4 after losing

routes to local sources. PR984946

• In AT route-group scenario, source route is flapped on preferred serving site. After that

the member site fails to originate type-4 even though it has type-5 and type-3 from

non-preferred serving sites. PR994687


















• WhenMAC addresses move, Layer 2 address learning process (l2ald) will be called

and produces some other child processes. The child processes cannot be terminated.

Thenmaximum process limitation is reached and the Routing Engine is locked up.

PR943026

General Routing

• Whengr- interface is disabled, theDECAP-NHalsoneeds tobedeleted / set todiscard.

PR791277

• When transit packets with TTL expired is received, FPC is responsible for sending an

ICMPTTLExpiredmessageback to thesender.There isa500ppsperPacketForwarding

Engine rate limit so that FPC is not overwhelmed when large volume of transit traffic

with TTL expired is received. PR893598

• MXVC /kernel: rts_ifstate_client_open:Number of ifstate clients have reached

threshold,current = 63maximum = 63. PR894974

• OnMXSeriesplatformswithMPC4E-3D-32XGE-SFFP/MIC3-3D-10XGE-SFPPequipped,

10G ports of these cards might stay offline where a link flaps or an SFP+ is inserted

after above 3months of link up. PR905589

• This PR addresses a timing issue, which happens when "no-vrf-propagate-ttl" is

configured in the routing-instance configuration. When this configuration is present, it

might sometime create a situationwhere the route selection happens of a routewhich

is yet to be resolved in secondary vrf table, which results in a RPD core. PR917536

• MX80 routers now support CLI command "show system resource-monitor summary".

PR925794

• In the Point-to-Point Protocol over Ethernet (PPPoE) scenario, for access or

access-internal routes using an unnumbered interface, if MAC is not specified along

withqualified-nexthop, the routingprotocolprocess (rpd)will fabricateaMACaddress

for it. When the access route or point-to-point interface itself is brought down, the rpd

created qualified-nexthop is being freed, due tomismatch between qualified-nexthop

and the kernel created point-to-point nexthop, rpd crashes and a core file is generated.

PR935978

• Some "service-set" have already existed, when add/delete "stateful-firewall-rules"

about more than 400 lines to the existing "service-set", then execute commit, the

traffic stopped and never restore without offline/online MS-MIC. PR937489

• In subscriber management environment, profile database files at backup Routing

Engineget corruptedwhen thedynamicprofile versioningandcommit fast-synchronize

are enabled in configuration. After GRES when the backup Routing Engine become

master, all the existing DHCP subscribers stuck in RELEASE State and new DHCP

subscribers can't bind at this point. PR941780

• DS0/T1 channel throughput on "16x CHE1T1, RJ48" card with PPP/CISCO-HDLC is not

N*64kbps. PR944287


Resolved Issues
















• PIC level "account-layer2-overhead" knob with ethernet-bridge doesn't add

"Adjustment Bytes". As a workaround, configure it under interface level. PR946131

• Egress multicast statistics display incorrectly after flapping of ae member links on

M320 or T Series FPC (M320 non-E3 FPC and T Series non-ES FPC). PR946760

• With scaled configuration of ATM VCs (~4000 VCs) on a single

MIC-3D-8OC3-2OC12-ATM ATMMIC, the MICmight crash. The crash is not seen with

lower scale (i.e. less than 3500 VCs per MIC). PR947434

• When configuring "no-readvertise" flag to existing static route, then this static route

will not exported to other VPN routing and forwarding (VRF) tables from onwards

which is expected. However, for the static route that has already exported to other

VRF tables before "no-readvertise" configuration, no deletion event occurs. Also, the

"rt-export" bit still set for the static routewhich is exported to other routing tables after

"no-readvertise" configuration. PR950994

• CLI command "show interfaces queue" does not account for interface queue drops

due to Head drops. This resulted in the "Queued" packets/bytes counter to be less

than what was actually received and dropped on that interface queue. This PR fixes

this issue. Head-drops, being a type of REDmechanism, are now accounted under the

"RED-dropped" section of the CLI command "show interfaces queue". PR951235

• In a scaled network and on amulti-chassis platformwith BGP ECMP configured, when

themaster Routing Engine of line-card chassis (LCC) crashes, LCC would go through

a reboot process to bring up the backup Routing Engine, during which the neighbor

session of BGP over aggregated Ethernet (AE) interface might get broken. This is

because the Unilist NHs of the AE are stuck at standby state and therefore no traffic

can be transmit through. PR953365

• On systems running Junos OS Release 13.3R1 and nonstop active routing (NSR) is

enabled, when "switchover-on-routing-crash" under [edit set system] hierarchy is set,

Routing Engine switchover should happen only when the routing protocol process

(rpd)crashes.ButunexpectedRoutingEngineswitchover canbeseenwhenperforming

the CLI command "request system core-dump routing running" to manually generate

a rpd live core.

• If an aggregated Ethernet (AE) interface has the "scaled" member-link scheduling

mode (which is the default mode), andmultiple forwarding-classes map to a same

queue, then the actual transmit-percent might be unable to reach the configured

scheduler. PR954789

• Default threshold for ES-FPC errors is 1 for major errors and 10 for minor errors, when

the threshold is reached, some actions (for example,

alarm|offline-pic|log|get-state|offline|reset) will be taken by FPC as configured. This

feature isdesigned forpermament/real errors.The issuehere is thatevensometransient

errors (eg, link flaps) will also trigger the default action. In some cases, it might cause

panic for the FPC. PR961165

• Sessions are getting reset when SFW rule and/or NAT term are added/deleted in a

service set having NAT also. PR961353

• On T Series or M320 routers with OSPF knob, if have large-scale routes (for example,

180K Composite Nexthop), when do costing-out and costing-in operations alongwith













changing gigether-options of core router facing interface multiple times continuously,

the Flexible PIC Concentrator (FPC) CPU utilizationmight increase to 100%, and then

FPCmight crash.

• On an MX Series router with dynamic vlan scenario, when improper sort order data is

sent to dynamic vlan on the Packet Forwarding Engine, theModular Port Concentrator

(MPC)might crash and generate core files. PR961645

• For MXVC platform, the pfe reconnect timer extends from the default 15s to 60s

temporarily. This will be reversed once Packet Forwarding Engine connection issues

resolved. PR963576

• Display issue only. "show route cumulative vpn-family" command is using "inet.6" for

vpnv6 routes instead of inet6.0. PR966828

• Destination alarms are cleared after fabric event even though destination errors are

present in the system. PR967013

• NHtracingprovidesa lightweightmechanismtocaptureNHchains traversedbypackets

of interest for further examination. PR967450


• /var/log/messages is getting filled up with following GRES relatedmessages. These

are harmless and due to the log level(info). *** messages *** Dec 1 22:46:49.201 re0

/kernel: update_slave_peer_gres_status: vksid 0 is_slave_peer_gres_ready 1

is_local_slave_peer_gres_ready 0 Dec 1 22:46:49.201 re0 /kernel: vks[0] 1 vks[1] 0 Dec

1 22:46:49.201 re0 /kernel: PFE-MASTER - vks[0] 1 vks[1] 0 Dec 1 22:46:49.201 re0

/kernel: Slave is ready for GRES for vksid 0 Dec 1 22:46:49.201 re0 /kernel:

update_slave_peer_gres_status: vksid 0 is_slave_peer_gres_ready 1









is_local_slave_peer_gres_ready 0Dec 1 22:46:53.000 re0 /kernel: vks[0] 1 vks[1] 0 Dec


/kernel: Slave is ready for GRES for vksid 0

• Whenperformingaunified in-service softwareupgrade (ISSU)validateagainst a router

with ISSU unsupported hardware equipped, the unsupported hardware is being taken

offline, as if an actual ISSU is being performed. In addition, the unsupported hardware

is still offline after the ISSU validate is completed. The workaround is rebooting or

executing CLI commands to bring the offline hardware back online. PR949882


Resolved Issues









Infrastructure

• On RE-S-1800 family of Routing Engines, after an intensive writing to SSD, the

immediate rebooting might cause SSD to corrupt. PR937774


• The Packet Forwarding Engine alarms raised by PFEMAN thread using cmalarm api

calls will not be transmitted to the Routing Engine. As impact, these alarms will not

reflect on the Routing Engine. There is no impact on functionality, otherwise.PR921254

• Traffic that uses MPLS next-hops enters bridge-domain via IRB interface and if

forwardingnext-hopmoves fromnon-aggregate interface toaggregate interface (MAC

move), the MPLS next-hops are not correctly programmed in the Packet Forwarding

Engine and are dropped. The child next-hop of the aggregate interfaces are missing.

Once IRBMPLSnext-hopmoves fromaggregate interface to non-aggregate interfaces

are not affected. IPv4 traffic will not trigger traffic drop uponmacmove. The second

symptom is a possible kernel core-dump on the new backup Routing-Engine after

mastership switch. This applies to an IRBmacmove for ipv4,ipv6 andmpls next-hops.

PR924015

• "Toomany I2C Failures" alarm happens when a FRU (in this case:

PWR-MX960-4100-AC-S) experienced six consecutive i2c read/write failures. While

thePEM is still providing power to the chassis, the chassisd daemon cannot read/write

information from the PEM until it is reseated. In recent investigation, engineering team

has come up some enhancements for this MX960 HC AC PEM: 1. PEM i2c bus hang

avoidance 2. Junos OS recovery from a hung i2c bus 3. noise reduction This Junos OS

eliminates theneed for thePEMFWupgrade,andat thesametime is 100%compatible

with those PEMs which have been upgraded. PR928861

• Traffic is not flowing over Demux input interface A technical description can be found

in the Knowledge Base: http://kb.juniper.net/KB28821. PR937035

• PCS statistics counter(Bit errors/Errored blocks) not working on Mammoth PIC(xge).

PR942719

• Digital Optical Monitoring MIB jnxDomCurrentRxLaserPower gives wrong value in

12.3R3-S6. PR946758

• When Connectivity Fault Management (CFM) is configured, if maintenance domain

intermediate point (MIP) session associated with default maintenance domain (MD)

is inactive, a deletion of the interface cannot delete the MIP session structure, hence

might causing memory leak. This crash could also be seen if delete more than one

Virtual private LAN service (VPLS) routing instance with no neighbor configuration.

PR947499

• When transit traffic of Ethernet frames of size less than 64 bytes is received by 1x

10GE(LAN/WAN) IQ2E PIC, the router forwards the frames instead of dropping them.

• Before the problemwas fixed, the CLI "show interfaces et-x/x/x extensive” did not give

full information. PR956497


937774 is rebooted.Thisproblemwill notbeobservedduring theupgrade to this install.















It occurs late enough in the shutdownprocedure that it shouldn't interferewith normal

operation.PR956691

• Whenmicro Bidirectional Forwarding Detection (mBFD) is configured on aggregated

Ethernet (AE) interface, if a member link of the AE interface is removed, if a member

link is marked admin down or disabled at CLI, the BFD session would correspondingly

bedown.However, the correspondingmember link in thepeer endcontinues to forward

traffic. PR963314

• In a very uncommon situation, we see that LCCs chassisd state is inconsistent with

SFC chassisd state. This is very misleading in troubleshooting stage. PR963342

Layer 2 Features

• Service accounting interim updates not being sent. PR940179

• In the unified in-service software upgrade (ISSU) for Dynamic Host Configuration

Protocol (DHCP) scenario, when ISSU initiates, if there are some subscribers stuck in

login state and keep sending discover/request packets, this leads to ISSU ready check

failing and ISSU aborting as a result. PR949337

• IP address change of a DHCP relay interface does not get reflected in gateway IP

address (giaddr) whenmaintain-subscribers knob is enabled, which needs to restart

DHCP daemon tomake it work again. PR951909

• When link level adjacency across IRB interface goes down, targeted LDP sessionmight

also go down even if there is a alternate route. PR959396

MPLS

• When static LSPs are configured on a node, RPD could assert upon committing a

MPLS-related configuration change. Example: router> show system rollback compare

9 8 [edit protocols mpls] interface ae11.0 { ... } + interface as3.0 { + admin-group red;

+} [edit protocols isis interface as3.0 level 2] ! inactive: metric 2610; The following

error is seen in /var/log/messages in-relation to a static lsp, immediately following the

above-mentioned configuration change: rpd[1583]: UI_CONFIGURATION_ERROR:

Process: rpd, path: [edit groups STATELESS_ARIADNE protocols mpls

static-label-switched-path static-lsp], statement: transit 1033465, static-lsp:

incoming-label 1033465hasalreadybeenconfiguredby thisorother staticapplications.

PR930058

• MXSeries routerswithFPCscouldcrashduringnext-hop resolution triggeredby indirect

next-hop change. PR944393

• In certain circumstance, the Junos OS rpd route flash job and LDP connection job are

always running, starvingotherwork suchas stale routedeletion. These jobsare running

as LDP is continuously sending label map and label withdrawmessages for some of

the prefixes under ldp egress policy. This is due to LDP processing a BGP route from

inet.3 forwhich it has a ingress tunnel (the sameprefix is also learned via IGP) creating

a circular dependency as BGP routes can themselves be resolved over a LDP route.

PR945234

• In a highly scaled configuration, the reroute of transit RSVP LSPs can result in BGP flap

due to lack of keepalive messages being generated by the Routing Engine. PR946030


Resolved Issues














• TheRSVPbandwidth of the aggregatedEthernet (AE) bundle does not adjust properly

when amember link is added to AE interface, and at the same time an IP address is

removed from this AE bundle. PR948690

• On IS-IS interfaces configured with point-to-point and ldp-synchronization, after a

change of IP address on the interface from the remote router, and if the old Label

Distribution Protocol (LDP) adjacency times-out after the new LDP adjacency is up,

the IS-IS protocol will be notified about the old LDP adjacency down event and the

LDP sync state will remain in "hold-down" even if the new LDP adjacency is up.

PR955219

• When Packet Forwarding Engine fast reroute (FRR) applications are in use (such as

MPLS facility backup, fast-reroute, loop free alternates), a flap of the primary path

could be triggered due to an interface flap or by Bidirectional Forwarding Detection

(BFD) session flap. However, this interface/session flap might lead to a permanent

use of the backup path, which means the original primary path could not be active

again. PR955231

• We add timer for all aggregate LDP prefixes but are not deleting it when the timer

expires because of a bug. Since the timer is not expiring, we never update the route for

any change. This will be sitting in the routing table as a stale entry. PR956661

• The Label Distribution Protocol (LDP) feature is enabled and the background job "LDP

sync send filtered label job" is running, when shut down the LDP, due to LDP failing to

delete a job that didn't exist while shutting down, routing protocol process (rpd)might

crash.


• In an MX-VC environment, in certain situations the inter-chassis traffic might not be

equally balanced across all available vcp links after adding extra links. PR915383

• Transit traffic is being improperly classified and competing with legitimate control

plane traffic. PR924807

• With MX Series routers with MPCs or MICs, changing the MTU on one interface might

cause Layer 2 traffic interruption on other interfaces in the same FPC. PR935090

• When chained-composite-nexthop ingress L3VPN is configured, and if two PEs are

directly connected, the unicast nexhhop on egress is IPv4 protocol encapsulated only

and no LSP label push, thus COS rewrite mask could not correctly set by IPv4 Unicast

nexthop, which leads to MPLS exp rewrite not working. PR941066

• TWAMP connection/session will come up only if the session padding length is greater

than or equal to 27 bytes on the TWAMP Client. The valid range of padding length

supportedby theTWAMPServer is 27bytes to 1400bytes. If IXIA is usedas theTWAMP

Client, packet length range from 41 bytes to 1024 bytes is supported. PR943320

• In a highly congested system (for example, high multicast traffic rate),

traffic/subscribers lossmightoccurwhileperformingunified in-servicesoftwareupgrade

(ISSU).

• On I-chipplatforms,when forwarding table filter (FTF) is configured for a virtual private

LAN service (VPLS) routing instance, the jtree memory corruption might occur if the














routing table attached by FTF is destroyed. The routing table that is attached by FTF

can get destroyed with different events such as an interface that is part of the VPLS

routing instance flaps or route-distinguisher is changed. PR945669

• Tested with 13.3 daily image "13.3-20140101.0". Issue not observed. Able to see both

the vlan fields updated properly. PR946964

• OnMX Series routers with MPCs, whenmulticast traffic flows over the integrated

routing and bridging (IRB) interfaces, MPCmight crash due to memory leak. PR947112

• In PPPoE subscriber management environment, if the BRAS router is an MX Series

router with MS-DPC equipped and traffic from the subscribers is NATed on MS-DPC

card, when PPPoE subscribers flap, heapmemory leak might occur on the MS-DPC.

PR948031

• MIC-3D-40GE-TX (3D 40x 1GE(LAN) RJ45) restarts with core files repeatedly after

configuring "VRRP interface" and "traffic-managermode ingress-and-egress" onPIC2

or PIC3. PR950806

• Current display of "cli> request chassis routing-engine hard-disk-test show-status"

command for Unigen SSD identified by "UGB94BPHxxxxxx-KCI" is incorrect and can

bemisleading when used for troubleshooting. For example, attribute 199 is displayed

as "UDMA CRC Error Count" and is actually "Total Count of Write Sector". PR951277

• Trafficunbalancecanbeseen inoutput interfaceof2ndnode in thecascaded topology.

Current Junos OS hash-seed implementation onMX Series routers with MPCs or MICs

can be used to protect the hash-cascade problem(unbalance at 2nd node output,

0:100 for example) but it doesn't work very well (60:40 or 70:30 can be seen). The fix

made an enhancement, so that it can deliver nearly 50:50 LB performance.PR953243

• OnMX Series or T4000 router, when a firewall filter is applied to allow only trusted IP

and router loopback address to request NTP service on the router in case of NTPDDoS

attack, the counter for the NTP protocol of the output of "show ddos-protection

protocols ntp" would be always null, though it is confirmed that there is an NTP DDoS

attack. The reason for this is that the only the multicast NTP packet is treated as an

NTP packet by the filter, whereas the unicast one is not. PR954862

• Whenoperating inenhanced-IPmode, forbridge-domains/vpls instanceswithsnooping

configuration, multicast data forwarding does not happen properly for multicast data

that is being routed over IRB interfaces associated with the bridge-domains/vpls

instances to egress on trunk ports associatedwith the bridge-domains/vpls instances.

PR955553

• rmopd will throw an error without jcrypto package which is absent in export build.

Domestic versiondoes not have this error becauseof thepresenceof jcrypto. The issue

exists in only Release 13.3 and not on branches before that. PR960757

• In current Junos OS, a PSM shows dc output value even though it is turned off by a

switch. This cosmetic bug causes miscalculation of actual usage in 'show chassis

power'. PR960865

• Upon the deletion of a routing-instance and subsequent commit, error logs are

generated from each Type 1 - 3(non E3) based FPC. These logs are cosmetic and can

be ignored. PR964326


Resolved Issues
















• Policy with Install-nexthop lspmight not work as expected when there is an LSP path

change triggering route resolution. PR931741

• Configurationofanextendedcommunity suchas: rt-import:*:* src-as:*:* fails because

the wildcard is not allowed during the configuration validation process. PR944400

Routing Protocols

• OnMX Series routers containing multiple Packet Forwarding Engines such as

MX240/MX480/MX960/MX2010/MX2020 routers, with DPC (Dense Port

Concentrator) or FPC (Flexible Port Concentrator) or with line cards designated with

"3D",RPDmight restartwhenattempting tosendaPIMassertmessageonan interface

(whose interface index exceeds 65536). It is likely that RPD restarts repeatedly, since

after RPDhas restarted andprotocols have converged, the samePIMassertwill trigger

further RPD restarts. PR879981

• On the first hop router if the traffic is received from a remote source and the

accept-remote-source knob is configured, the RPF information for the remote source

is not created. PR932405

• Due to new features and the required infrastructure the rpdmemory footprint has

increased by as much as 5% between Releases 12.3 and 13.3. PR957550

• In scaled BGP routes environment, the BGP router has dual Routing Engines, graceful

Routing Engine switchover (GRES) and nonstop active routing (NSR) is configured,

after performing the operation of deactivate/activate BGP groups and commit the

configuration, the BGP router might be stuck in "not-advertising" state. PR961459

• With BGP import policy as next-hop peer-address, if the local router receives inet (or

inet-vpn) flownetwork-layer reachability information (NLRI), routing protocol process

(rpd)might crash. JunosOS is designed to create a fictitious next hop for inet flow and

inet-vpn flow families as they don't send/expect-to-receive next hops. So in this case

when the import-policy set a non-null next-hop for the received inet (or inet-vpn) flow

route, it could not handle it properly which might result in rpd crash. PR966130

• In a scaled setup, if BGP peers flap during an NSR, the sessions can end up out of sync

between themaster andbackupRoutingEngines. To recover youcanclear theaffected

neighbors. PR966206

• In a highly scaled setup after anNSR, someBGP sessionsmight be idle on bothmaster

andbackupRoutingEngines. To recover, clear theaffectedpeerusing theCLI.PR967788


• SIP call forwarding might fail when NAT is used between parties even though the SIP

ALG is in use. PR839629

• Junos OS Release 11.4 introduced the IKEv2 support and a stricter check on IKE/IPsec

SAs proposal parameters. PR843893

• DNSmultiple queries A and AAAAmight cause the Service-PIC to restart. PR943425















• During a rare scenario, switchover on another sp interface can crash a servicePICwhen

running traffic in hairpinning scenario. PR945114

• Jl2tpd process experiences high CPU condition if the process is restarted or if GRES is

executed. The jl2tpd process does recover. The length of the high CPU condition is

directly proportional to the number of tunnels on average, it is 1 second per tunnel.

PR955378


• LNS-Service accounting updates not sent. PR944807

• Radiusattribute ignore logical-system-routing-instancenot ignoringVSA26-1.PR953802

• Configuration change of the IPv4 address range in address-assignment pool does not

always take effect. PR954793


• If a configuration file that contains groups related configuration is loaded by command

"load replace", a "commit confirmed" operationmight fail.When this issue occurs, the

new configuration is committed even if you do not confirm it within the specified time

limit. PR925512

VPNs

• The issue happens when the virtual routing forwarding (vrf) is configured

"no-vrf-propagate-ttl" and the vrf import policy changes the local preference of the

vrf route. With "no-vrf-propagate-ttl", BGP will resolve the primary l3vpn route and

the vrf secondary route separately. The root cause is overwriting the route parameters

of the second vrf route with the route parameters of the primary route. So changes to

the local preference of the vrf route might not work. PR935574

• NGMVPNreceiverPEdoesnotgenerateTYPE4 routeafter receivingTYPE3.PR953449

• With these high amount of streams, we have a higher number of data-mdt-tlvs to

process which is becoming a bottleneck. PR957280

• Before Release 13.3R2, if no loopback interface inside vrf was configured, then Rosen

V6might not be able to use default main loopback as source for PE_PE pim

communications., As a result, Rosen v6 neighbor will not be formed toward remote

PEs. PR966825










Resolved Issues













This section lists the errata and changes in Junos OS Release 13.3R4 documentation for

the M Series, MX Series, and T Series.

• Aggregated Ethernet Interfaces Feature Guide for Routing Devices on page 106

• Chassis-Level Feature Guide on page 109

• Class of Service Library for Routing Devices on page 110

• Dynamic Firewall Feature Guide for Subscriber Services on page 110

• Ethernet Interfaces Feature Guide on page 111

• Ethernet Networking Feature Guide for MX Series Routers on page 111

• Firewall Filters Feature Guide for Routing Devices on page 113

• Interchassis Redundancy Using Virtual Chassis Feature Guide for MX Series

Routers on page 113

• IP Demux Interfaces over Static or Dynamic VLAN Demux Interfaces on page 114

• Junos Address-Aware Carrier-Grade NAT and IPv6 Feature Guide on page 114

• Layer 2 Configuration Guide, Bridging, Address Learning, and Forwarding on page 115

• Layer 2 VPNs Feature Guide for Routing Devices on page 116

• Network Management Administration Guide for Routing Devices on page 116

• Protocol Family and Interface Address Properties on page 117

• Services Interfaces Configuration Guide on page 117

• Standards Reference on page 122

• Subscriber Management Feature Guide on page 122

• System Log Messages Reference on page 124

• Unified ISSU System Requirements on page 124

• Virtual Chassis support on MX104 routers on page 124

• VPLS Feature Guide for Routing Devices on page 124

• VPWS Feature Guide for Routing Devices on page 124

Aggregated Ethernet Interfaces Feature Guide for Routing Devices

• The following enhancements and additions apply to the “Example: Configuring

Multichassis Link Aggregation in an Active- Active Bridging Domain on MX Series

Routers” topic:

• The Topology Diagram section fails to mention that interface ge-1/0/2 functions as

the ICCP link between the two PE devices, interface ge-1/1/1 is the ICL-PL link, and

interface ge-1/1/4 is the link that connects to the server or theMC- LAG client device.

• As a best practice, we recommend that you configure the ICCP and ICL interfaces

over aggregated Ethernet interfaces instead of other interfaces such as Gigabit

Ethernet interfaces, depending on your topology requirements and framework.



• Youmust disable RSTP on the ICL-PL interfaces for an MC-LAG in an active-active

bridging domain.

• The Step-by-Step Procedure section for Router PE2 that is illustrated in the example

is missing, although the quick configuration statements are presented.

To configure Router PE2:

1. Specify the number of aggregated Ethernet interfaces to be created.

[edit chassis]user@PE2# set aggregated-devices ethernet device-count 5

2. Specify the members to be included within the aggregated Ethernet bundles.

[edit interfaces]user@PE2# set ge-1/0/5 gigether-options 802.3ad ae1user@PE2# set ge-1/1/0 gigether-options 802.3ad ae0

3. Configure the interfaces that connect to senders or receivers, the ICL interfaces,and the ICCP interfaces.

[edit interfaces]user@PE2# set ge-1/0/3 flexible-vlan-tagginguser@PE2# set ge-1/0/3 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/3 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/3 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/4 flexible-vlan-tagginguser@PE2# set ge-1/0/4 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/4 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/4 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/5 gigether-options 802.3ad ae0user@PE2# set ge-1/1/0 gigether-options 802.3ad ae1

4. Configure parameters on the aggregated Ethernet bundles.

[edit interfaces ae0]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2#setunit0multi-chassis-protection 100.100.100.1 interfacege-1/0/4.0

[edit interfaces ae1]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2#setunit0multi-chassis-protection 100.100.100.1 interfacege-1/0/4.0

5. Configure LACP on the aggregated Ethernet bundles.

[edit interfaces ae0 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1



[edit interfaces ae1 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1

6. Configure the MC-LAG interfaces.

[edit interfaces ae0 aggregated-ether-options]user@PE2# setmc-aemc-ae-id 5user@PE2# setmc-ae redundancy-group 10user@PE2# setmc-ae chassis-id 1user@PE2# setmc-aemode active-activeuser@PE2# setmc-ae status-control active

[edit interfaces ae1 aggregated-ether-options]user@PE2# setmc-aemc-ae-id 10user@PE2# setmc-ae redundancy-group 10user@PE2# setmc-ae chassis-id 1user@PE2# setmc-aemode active-activeuser@PE2# setmc-ae status-control active

Themultichassis aggregatedEthernet identificationnumber (mc-ae-id) specifies

which link aggregation group the aggregated Ethernet interface belongs to. The

ae0 interfaces on Router PE1 and Router PE2 are configuredwithmc-ae-id 5. The

ae1 interfaces on Router PE1 and Router PE2 are configured withmc-ae-id 10.

The redundancy-group 10 statement is usedby ICCP toassociatemultiple chassis

that perform similar redundancy functions and to establish a communication

channel so thatapplicationsonpeeringchassis cansendmessages toeachother.

The ae0 and ae1 interfaces on Router PE1 and Router PE2 are configuredwith the

same redundancy group redundancy-group 10.

The chassis-id statement is used by LACP for calculating the port number of the

MC-LAG's physical member links. Router PE2 uses chassid-id 1 to identify both

its ae0 and ae1 interfaces. Router PE2 uses chassis-id 0 to identify both its ae0

and ae1 interfaces.

Themode statement indicates whether anMC-LAG is in active-standbymode or

active-activemode.Chassis thatare in thesamegroupmustbe in thesamemode.

7. Configure a domain that includes the set of logical ports.

[edit bridge-domains bd0]user@PE2# set domain-type bridgeuser@PE2# set vlan-id alluser@PE2# set service-id 20user@PE2# set interface ae0.0user@PE2# set interface ae1.0user@PE2# set interface ge-1/0/3.0user@PE2# set interface ge-1/1/1.0user@PE2# set interface ge-1/1/4.0

The ports within a bridge domain share the same flooding or broadcast

characteristics in order to perform Layer 2 bridging.



The bridge-level service-id statement is required to link related bridge domains

across peers (in this case Router PE1 and Router PE2), and should be configured

with the same value.

8. Configure ICCP parameters.

[edit protocols iccp]user@PE2# set local-ip-addr 100.100.100.2user@PE2# set peer 100.100.100.1 redundancy-group-id-list 10user@PE2# set peer 100.100.100.1 liveness-detectionminimum-interval 1000

9. Configure the service ID at the global level.

[edit switch-options]user@PE2# set service-id 10

Youmust configure the same unique network-wide configuration for a service in

the set of PE routers providing the service. This service ID is required if the

multichassis aggregated Ethernet interfaces are part of a bridge domain.

Chassis-Level Feature Guide

• The following additional information regarding the compatibility of modules for the

interoperationofRPMclientsandRPMservers applies to the “ConfiguringRPMProbes”

section in the “Configuring Real-Time Performance Monitoring” topic:

Keep the following points in mind when you configure RPM clients and RPM servers:

• You cannot configure an RPM client that is PIC-based and an RPM server that is

based on either the Packet Forwarding Engine or Routing Engine to receive the RPM

probes.

• You cannot configure an RPM client that is Packet Forwarding Engine-based and an

RPM server that receives the RPM probes to be on the PIC or Routing Engine.

• The RPM client and RPM server must be located on the same type of module. For

example, if the RPM client is PIC-based, the RPM server must also be PIC-based,

and if the RPM server is Packet Forwarding Engine-based, the RPM client must also

be Packet Forwarding Engine-based.

• The show chassis fabric unreachable-destinations command is incorrectly mentioned

as supported on MX240, MX480, and MX960 routers from Junos OS Release 11.4R2

and JunosOSRelease 12.1. TheSupportedPlatformssectionof this topicalso incorrectly

state MX240, MX480, and MX960 routers as supported routers for this command.

This command is not available on the MX240, MX480, and MX960 routers. Instead,

the correct command is the showchassis fabric destinations command, which you can

use to view the state of fabric destinations for all FPCs.

• The followingadditional information regarding theprocessingofTWAMPtraffic applies

to the "Configuring TWAMP Servers" section in the "Configuring TWAMP" topic:

The preceding configuration settings that are described define a TWAMP server on the

router that enables a TWAMPclient to connect to the server using anymedia interface

IP address such as a ge- interface. In such a scenario, the router functions as a TWAMP

server and timestamping is performed in the ukernel of the media-facing FPC.



To configure an inline TWAMP server, which causes timestamping to be performed as

part of the inline services (si-) interfaceprocessing, configure theamountof bandwidth

reserved on each Packet Forwarding Engine for tunnel traffic using inline services by

including the bandwidth (1g | 10g) statement at the [edit chassis fpc slot-number pic

number inline-services] hierarchy level and specify the service PIC logical interface that

provides the TWAMP service by including the twamp-server statement at the [edit

interfaces sp-fpc/pic/port unit logical-unit- number family inet] hierarchy level.

• The description of the check option available with the request chassis routing-engine

master command topic fails to state that this option is supported on MX104 routers

and PTX5000 routers, in addition to the list of devicemodelsmentioned in that topic.

Also, this option is incorrectly stated as supported on MX240 routers, whereas this

option is not supported on those routers.

• The network-services configuration statement topic inadvertently fails to state that

the enhanced network servicesmode settings, such as the enhanced-ethernet and the

enhanced-ip option, are supported on MS-MPCs on MX Series routers.

• The "Configuring Redundancy Fabric Mode for Active Control Boards on MX Series

Routers" topic incorrectly states that on MX routers that contain the enhanced SCB

with Trio chips and the MPC3E, redundancy mode is enabled by default. The correct

default behavior is that on MX routers that contain the enhanced SCB, regardless of

the type of DPC or MPC installed on it, the default mode is the redundancy mode.

Class of Service Library for Routing Devices

• The Applying Scheduler Maps and Shaping Rate to DLCIs and VLANs and Scaling of

Per-VLAN Queuing on Non-Queuing MPCs topics in the CoS Output Queuing and

Scheduling Feature Guide for Routing Devices fails to mention that you can configure

can also configure logical interface scheduling on the 8x10GE ports of an 2x100GE +

8x10GEMPC4E, apart the 2x100GE ports.

Dynamic Firewall Feature Guide for Subscriber Services

• The enhanced-policer topic fails to include a reference to the “Enhanced Policer

Statistics Overview” topic. The overview topic explains how the enhanced policer

enables you to analyze traffic statistics for debugging purposes.

The enhanced policer statistics are as follows:

• Offered packet statistics for traffic subjected to policing.

• OOSpacket statistics for packets that aremarkedout-of-specificationby thepolicer.

Changes to all packets that have out-of-specification actions, such as discard, color

marking, or forwarding-class, are included in this counter.

• Transmitted packet statistics for traffic that is not discarded by the policer. When

the policer action is discard, the statistics are the same as the in-spec statistics;

when thepoliceraction isnon-discard(loss-priorityor forwarding-class), thestatistics

are included in this counter.

To enable collection of enhanced statistics, include the enhanced-policer statement

at the [edit chassis] hierarchy level. To view these statistics, include the detail option



when you issue the show firewall, show firewall filter filter-name, or show policer

command.

Ethernet Interfaces Feature Guide

• In theOutput Fields sectionof the show interfaces(10-GigabitEthernet), show interfaces

(GigabitEthernet), and show interfaces(FastEthernet)command topicsof theEthernet

Interfaces Feature Guide, the descriptions of theBit errors and Erroredblocks fields that

are displayed under the PCS Statistics section of the output are ambiguous. The

following are the revised descriptions of these fields:

• Bit errors—The number of seconds during which at least one bit error rate (BER)

occurred while the PCS receiver is operating in normal mode.

• Errored blocks—The number of seconds when at least one errored block occurred

while the PCS receiver is operating in normal mode.

• The [edit protocols lacp] hierarchy level topic fails tomention that the ppmcentralized

statement is supported at this level for MX Series routers. This statement has been

supported from Junos OS Release 9.4. You can use the ppm statement to switch

between distributed and centralized periodic packet management (PPM). By default,

distributed PPM is active. To enable centralized PPM, include the ppm centralized

statement at the [edit protocols lacp] hierarchy level. You can disable distributed PPM

processing for all packets that use PPM and run all PPM processing on the Routing

Engine by configuring the no-delegate-processing configuration statement at the [edit

routing-options ppm] statement hierarchy level.

Ethernet Networking Feature Guide for MX Series Routers

• The following corrections apply to the “Example: Configuring One VPLS Instance for

Several VLANs” topic:

The following sentence is erroneously presented:

If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and

vlan-id-list-range statements provide a way to switch all of these VLANs with a

minimum configuration effort and fewer switch resources.

The correct description is as follows:

If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and

vlan-id-list statements provide a way to switch all of these VLANs with aminimum

configuration effort and fewer switch resources.

The following example replaces the existing example that illustrates the use of the

vlan-id all statement:

[edit]interfaces ge-1/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;unit 1 {encapsulation vlan-vpls;family bridge {interface-mode trunk;



vlan-id-list 1-1000; # Note the use of the VLAN id list statement.}

}unit 11 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1500;

}}

}interfaces ge-2/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;unit 1 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.

}}

}interfaces ge-3/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;family bridge {unit 1 {encapsulation vlan-vpls;interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.

}}

}interfaces ge-6/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;family bridge {unit 11 {encapsulation vlan-vpls;interface-mode trunk;vlan-id-list 1500;

}}

}routing-instances {customer-c1-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.1;interface ge-2/0/0.1;interface ge-3/0/0.1;bridge-domains {c1-vlan-v1-to-v1000 {vlan-id all; # Note the use of the VLAN id all statement

}}

} # End of customer-c1-v1-to-v1000



customer-c2-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.11;interface ge-6/0/0.11;bridge-domains {c1-vlan-v1500 {vlan-id all; # Note the use of the VLAN id all statement

}}

} # End of customer-c1-v1500} # End of routing-instances

Note the use of the vlan-id all statement in the virtual-switch instance called

customer-c1-v1-to-v1000.

Firewall Filters Feature Guide for Routing Devices

• The following additional information regarding the decapsulation of GRE packets as

a terminatingaction for firewall filters applies to the "Firewall FilterTerminatingActions"

topic:

NOTE: Thedecapsulateaction that youconfigureat the [edit firewall family

inet filter filter-name term term-name]hierarchy leveldoesnotprocess traffic

with IPv4and IPv6options.Asa result, trafficwithsuchoptions isdiscardedby the decapsulation of GRE packets functionality.

Interchassis Redundancy Using Virtual Chassis Feature Guide for MX SeriesRouters

• In the Junos OS 13.2 Release Notes for M Series Multiservice Edge Routers, MX Series 3D

Universal Edge Routers, and T Series Core Routers, the Support for MX Series Virtual

Chassis (MXSeries routerswithMPC3E interfaces) feature description failed tomention

that you can configure a two-member MX Series Virtual Chassis on both MPC3E

modules and MPC4Emodules. The correct description for this feature is as follows:

• Support forMXSeriesVirtualChassisonMXSeries routerswithMPC3EandMPC4Einterfaces—Extendssupport for configuringa two-memberMXSeriesVirtualChassisto MX240, MX480, andMX960 routers with any of the followingmodules installed:

• MPC3E (model number MX-MPC3E-3D)

• 32x10GEMPC4E (Model number: MPC4E-3D-32XGE-SFPP)

• 2x100GE + 8x10GEMPC4E (Model number: MPC4E-3D-2CGE-8XGE)

All MX Series Virtual Chassis features are supported on these modules.

In earlier Junos OS releases, MX Series routers did not support MX Series Virtual

Chassis configuration on MPC3E and MPC4Emodules.



[See Junos OSHigh Availability Library for Routing Devices and Junos OS for MX Series

3D Universal Edge Routers.]

• The followingadditional informationapplies to theVirtualChassisComponentsOverview

topic in the Interchassis Redundancy Using Virtual Chassis Feature Guide for MX Series

Routers for Junos OS Release 11.2 and later releases.

When you configure chassis properties for MPCs installed in a member router in an

MX Series Virtual Chassis, keep the following points in mind:

• Statements included at the [edit chassis membermember-id fpc slot slot-number]

hierarchy level apply to the MPC (FPC) in the specified slot number only on the

specified member router in the Virtual Chassis.

For example, if you issue the set chassis member 0 fpc slot 1 power off statement,

only the MPC installed in slot 1 of member ID 0 in the Virtual Chassis is powered off.

• Statements included at the [edit chassis fpc slot slot-number] hierarchy level apply

to theMPCs(FPCs) in thespecifiedslotnumberoneachmember router in theVirtual

Chassis.

For example, if you issue the set chassis fpc slot 1 power off statement in a

two-member MX Series Virtual Chassis, both the MPC installed in slot 1 of member

ID 0 and the MPC installed in slot 1 of member ID 1 are powered off.

BEST PRACTICE: To ensure that the statement you use to configure MPCchassis properties in a Virtual Chassis applies to the intendedmemberrouter andMPC, we recommend that you always include themember

member-ID option before the fpc keyword, wheremember-id is 0 or 1 for a

two-member MX Series Virtual Chassis.

IP Demux Interfaces over Static or Dynamic VLANDemux Interfaces

• The “IP Demux Interfaces over Static or Dynamic VLAN Demux Interfaces” topic

incorrectly states thatbothDPCsandMPCssupportVLANdemuxsubscriber interfaces.

In fact, only MPCs support these interfaces.

Junos Address-Aware Carrier-Grade NAT and IPv6 Feature Guide

• The followingnoteapplies to the topic “ConfiguringAddressPools forNetworkAddress

Port Translation (NAPT) Overview”:

NOTE: When 99 percent of the total available ports in a pool for napt-44are used, no new flows are allowed on that NAT pool.

• Several errors were found in the configuration statements included in the “Example:

Configuring Inline Network Address Translation” topic. The topic has been corrected

on theweband in the “JunosAddressAwareCarrierGradeNATand IPv6FeatureGuide”

PDF.



http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/config-guide-high-availability/index.html

http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/mx-series/

http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/mx-series/

• The address-allocation statement topic fails to state the following additional

information regarding addresses allocation on MS-MICs and MS-MPCs:

Regardless of whether the round-robin method of allocation is addresses is enabled

byusing theaddress-allocationround-robinstatement, round-robinallocation isenabled

by default on MS-MICs and MS-MPCs.

• The topicConfiguringSecuredPortBlockAllocationcontainsanote listingconfiguration

changes that requirea rebootof the servicesPIC. Thenotehasbeenupdated to include

change to the NAT pool name.

• The following information regarding the guidelines for configuration of IP addresses

for NAT processing applies to the "Configuring Source and Destination Addresses

Network Address Translation Overview " section of the "Network Address Translation

Rules Overiew" topic:

The addresses that are specified as valid in the inet.0 routing table and not supported

for NAT translation are orlongermatch filter types. You cannot specify any regions

within such address prefixes in a NAT pool.

• The following information regarding the working of APP with NAT rules applies to the

"Network Address Translation Rules Overiew" topic:

For MX Series routers with MS-MICs and MS-MPCs, although the address pooling

paired (APP) functionality is enabledwithinaNAT rule (by including theaddress-pooling

statement at the [edit services nat rule rule-name term term-name then translated]

hierarchy level), it is a characteristic of a NAT pool. Such a NAT pool for which APP is

enabled cannot be shared with NAT rules that do not have APP configured.

Layer 2 Configuration Guide, Bridging, Address Learning, and Forwarding

• The following information regarding the differences in the default limit on MAC

addresses that can be learned on an access port and a trunk port is inadvertently

omitted from the “Limiting MAC Addresses Learned from an Interface in a Bridge

Domain” topic:

• For an access port, the default limit on the maximum number of MAC addresses

that can be learned on an access port is 1024. Because an access port can be

configured in only one bridge domain in a network topology, the default limit is 1024

addresses,which is sameas the limit forMACaddresses learnedona logical interface

in a bridge domain (configured by including the interface-mac-limit limit statement

at the [edit bridge-domains bridge-domain-name bridge-options interface

interface-name]or [editbridge-domainsbridge-domain-namebridge-options]hierarchy

level.

• For a trunk port, the default limit on the maximum number of MAC addresses that

can be learned on a trunk port is 8192. Because a trunk port can be associated with

multiple bride domains, the default limit is the same as the limit for MAC addresses

learned on a logical interface in a virtual switch instance (configured by including

the interface-mac-limit limit statement at the [edit routing-instances



routing-instance-name switch-options interface interface-name] for a virtual switch

instance).

Layer 2 VPNs Feature Guide for Routing Devices

• The descriptions of the pw-label-ttl-1 and router-alert-label options in the

control-channel (Protocols OAM) configuration statement topic are incorrectly and

interchangeably stated. The correct descriptions of these options are as follows:

• pw-label-ttl-1—For BGP-based pseudowires that send OAM packets with the MPLS

pseudowire label and time-to-live (TTL) set to 1.

• router-alert-label—For BGP-based pseudowires that send OAM packets with router

alert label.

NetworkManagement Administration Guide for Routing Devices

• The syntax of the filter-interfaces statement in the SNMPConfiguration Statement

section is incorrect. The correct syntax is as follows:

filter-interfaces {all-internal-interfaces;interfaces interface-names{interface 1;interface 2;

}}

[See filter-interfaces.]



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/filter-interfaces-edit-snmp.html

Protocol Family and Interface Address Properties

• The following additional information regarding the working of unnumbered interfaces

applies to the Example: Configuring an Unnumbered Ethernet Interface section in the

Configuring an Unnumbered Interface topic:

The sample configuration that is described works correctly on M Series and T Series

routers. For unnumbered interfaces on MX Series routers, youmust additionally

configure static routes on an unnumbered Ethernet interface by including the

qualified-next-hop statementat the [edit routing-optionsstatic routedestination-prefix]

hierarchy level to specify the unnumbered Ethernet interface as the next-hop interface

for a configured static route.

Services Interfaces Configuration Guide

• In the Lines of Sample DTCP Parameter File table in the “Flow-Tap Filter Operation”

topic, the description for the Seq:10 command contained in the DTCP file incorrectly

states that the router looks for a newer sequence number before accepting and

implementing new parameters, and that any configuration attempt with an older

sequence number is rejected by the dynamic flow capture process.

The following guideline correctly describes the processing of the Seq:10 command in

the DTCP file:

The router does not validate the sequence number attribute during any configuration

changes that are performed for a DTCP parameter file sent to the router from the

mediationdevice.Regardlessofwhether thesequencenumberconflictswithaprevious

sequence number or is unique, it is disregarded and not considered.

The following additional fields are missing from the Lines of Sample DTCP Parameter

File table:

DescriptionCommand

This indicates the DTCP version to be used. DTCP/0.6 should be used for all versions of Junos OS upto and including Junos OS 8.5. DTCP/0.7 should be used for Junos OS 9.0 and later. However, JunosOS 9.5R2 and later also accept previous versions of DTCP.

If any unsupported parameters are received for a particular DTCP version, the request is rejected.

NOTE: The notification responses from Junos OS contains the same DTCP version that the controlsource has communicated to Junos OS. For notifications being sent even before the control sourcehas contacted Junos OS, the DTCP version 0.7 will be used.

DELETE DTCP/0.6

This line denotes the ID that DTCP assigns for the mirrored session when you create a DTCP ADDmessage. Use this ID in your DELETEmessages to disable the intercept for a specific subscriber. Toview the ID, use the DTCP LISTmessage. The CRITERIA-ID and the Cdest-ID are mutually exclusive inDELETEmessages.

CRITERIA-ID:criteria-id

[See Flow-Tap Filter Operation.]

• The following additional information applies to the sample configuration described in

the “Example: Flow-Tap Configuration” topic of the “FlowMonitoring” chapter.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/flow-tap-filter-operation.html

NOTE: Thedescribedexampleappliesonly toMSeriesandTSeries routers,except M160 and TXMatrix routers. For MX Series routers, because theflow-tap application resides in the Packet Forwarding Engine rather thana service PIC or Dense Port Concentrator (DPC), the Packet ForwardingEnginemust send the packet to a tunnel logical (vt-) interface toencapsulate the interceptedpacket. In suchascenario, youneed toallocatea tunnel interface and assign it to the dynamic flow capture process forFlowTapLite to use.

• The following information is missing from the passive-mode-tunneling configuration

statement and the “Example: Configuring Junos VPN Site Secure on MSMIC and

MS-MPC” topic:

Passive module tunneling is not supported on MS-MICs and MS-MPCs.

• Theopen-timeout configuration statement topic and the “ConfiguringDefault Timeout

Settings for Services Interfaces” topic incorrectly state that the default value of the

timeout period for TCP session establishment is 30 seconds. The correct default value

is 5 seconds.

• The Supported Platforms section of theset chassis displaymessage command topic

erroneously states that this command is supportedonMXSeries routers.This command

is not available on MX Series routers.

• The following procedure applies to the “Provisioning Flow-Tap to a Linux Mediation

Device” topic

The following example shows the syntax to invoke the Perl script from a Linux device

for deleting a previously configured Flow-Tap session:

1. Invoke the Perl script:

[root@blr-e flowtap]# ./dfcclient.pl

2. Use the following line to push the parameter file del_lea1_tcp.flowtap to the router.

In this example, 10.209.75.199 is the IP address of the router, and verint verint123 is

the username and password that has permission to implement flow-tap-operation.

Any firewall that is between themediation device and the routing device should

allow ssh and port 32001.

[root@blr-e flowtap]# ./dfcclient.pl 10.209.75.199verintverint123del_lea1_tcp.flowtap

The following settings are contained in the del_lea1_tcp.flowtap DTCP parameter

file. DTCP DELETE can use either Criteria- ID to delete only that criteria or Cdest-ID

to delete everything with cdest-ID that you previously created.

DELETE DTCP/0.7Csource-ID: dtcpCdest-ID: LEA1Flags: STATIC

3. Use the show policer | match flow statement to verify that the flow-tap filter is

removed from the router:



The following sample shows how to disablemirroring for a specific subscriber by using

the CRITERIA-ID.

DELETE DTCP/0.7Csource-ID: dtcp1CRITERIA-ID: 2Flags: STATICSeq: 10Authentication-Info: 7e84ae871b12f2da023b038774115bb8d955f17e

DTCP/0.7 200 OKSEQ: 10CRITERIA-COUNT: 1TIMESTAMP: 2011-02-13 16:00:02.802AUTHENTICATION-INFO: 2834ff32ec07d84753a046cfb552e072cc27d50b

• The following additional information regarding the interoperation of sample actions

in firewall filters and traffic sampling applies to the “MinimumConfiguration for Traffic

Sampling” section in the “Configuring Traffic Sampling” topic:

The following prerequisites apply to M Series, MX Series, and T Series routers when

you configure traffic sampling on interfaces and in firewall filters:

• If you configure a sample action in a firewall filter for an inet or inet6 family on an

interfacewithout configuring the forwarding-options settings, operational problems

might occur if you also configure port mirroring or flow-tap functionalities. In such a

scenario, all the packets that match the firewall filter are incorrectly sent to the

service PIC.

• If you include the then sample statement at the [edit firewall family inet filter

filter-name term term-name] hierarchy level to specify a sample action in a firewall

filter for IPv4 packets, youmust also include the family inet statement at the [edit

forwarding-options sampling] hierarchy level or the instance instance-name family

inet statement at the [edit forwarding-options sampling] hierarchy level. Similarly,

if you include the then sample statement at the [edit firewall family inet6 filter

filter-name term term-name] hierarchy level to specify a sample action in a firewall

filter for IPv6 packets, youmust also include the family inet6 statement at the [edit

forwarding-options sampling] hierarchy level or the instance instance-name family

inet6 statementat the [edit forwarding-optionssampling]hierarchy level.Otherwise,

a commit error occurs when you attempt to commit the configuration.

• Also, if you configure traffic sampling on a logical interface by including the sampling

input or sampling output statements at the [edit interface interface-name unit

logical-unit-number] hierarchy level, you must also include the family inet | inet6

statement at the [edit forwarding-options sampling] hierarchy level, or the instance

instance-name family inet | inet6 statementat the [edit forwarding-optionssampling]

hierarchy level.

• The “Configuring Port Mirroring” topic erroneously states that the input statement can

be includedunder the [edit forwarding-optionsport-mirroringfamily(inet | inet6)output]

hierarchy level. Only the output statement is available at the [edit forwarding-options

port-mirroring family (inet | inet6)] hierarchy level. To configure the input packet

properties for port mirroring, youmust include the input statement at the [edit

forwarding-options port-mirroring] hierarchy level.



To configure port mirroring on a logical interface, configure the following statements

at the [edit forwarding-options port-mirroring] hierarchy level:

[edit forwarding-options port-mirroring]input {maximum-packet-length bytesrate rate;run-length number;

}family (inet|inet6) {output {interface interface-name {next-hop address;

}no-filter-check;}

}

Also, the note incorrectly states that the input statement can also be configured at the

[edit forwarding-options port-mirroring] hierarchy level and that it is only maintained

for backwardcompatibility. Thenotealsomentions that theconfigurationof theoutput

statement is deprecated at the [edit forwarding-optionsport-mirroring] hierarchy level.

The correct behavior regarding the port-mirroring configuration for the packets to be

mirrored and for the destination at which the packets are to be received is as follows:

NOTE: The input statement is deprecated at the [edit forwarding-options

port-mirroring family (inet | inet6)] hierarchy level and is maintained only

for backward compatibility. Youmust include the input statement at the

[edit forwarding-options port-mirroring] hierarchy level.

• In theOutput Fields section of the show services ipsec-vpn ipsec security-associations

command topic of the Junos VPN Site Secure Feature Guide, the descriptions of the

Local Identity and Remote Identity fields are not clear and complete. The following are

the revised descriptions of these fields:

• Local Identity—Protocol, address or prefix, and port number of the local entity of the

IPsec association. The format is id-type-name

(proto-name:port-number,[0..id-data-len] = iddata-presentation). The protocol is

alwaysdisplayedasanybecause it is not user-configurable in the IPsec rule. Similarly,

the port number field in the output is always displayed as 0 because it is not

user-configurable in the IPsec rule. The value of the id-data-len parameter can be

one of the following, depending on the address configured in the IPsec rule:

• For an IPv4 address, the length is 4 and the value displayed is 3.

• For a subnet mask of an IPv4 address, the length is 8 and the value displayed is 7.

• For a range of IPv4 addresses, the length is 8 and the value displayed is 7.

• For an IPv6 address prefix, the length is 16 and the value displayed is 15.



• Forasubnetmaskofan IPv6addressprefix, the length is32and thevaluedisplayed

is 31.

• For a range of IPv6 address prefixes, the length is 32 and the value displayed is 31.

The value of the id-data-presentation field denotes the IPv4 address or IPv6 prefix

details. If the fully qualified domain name (FQDN) is specified insteadof the address

for the local peer of the IPsec association, it is displayed instead of the address

details.

• Remote Identity—Protocol, address or prefix, and port number of the remote entity

of the IPsec association. The format is id-type-name

(proto-name:port-number,[0..id-data-len] = iddata-presentation). The protocol is

alwaysdisplayedasanybecause it is not user-configurable in the IPsec rule. Similarly,

the port number field in the output is always displayed as 0 because it is not

user-configurable in the IPsec rule. The value of the id-data-len parameter can be

one of the following, depending on the address configured in the IPsec rule:

• For an IPv4 address, the length is 4 and the value displayed is 3.

• For a subnet mask of an IPv4 address, the length is 8 and the value displayed is 7.

• For a range of IPv4 addresses, the length is 8 and the value displayed is 7.

• For an IPv6 address prefix, the length is 16 and the value displayed is 15.

• Forasubnetmaskofan IPv6addressprefix, the length is32and thevaluedisplayed

is 31.

• For a range of IPv6 address prefixes, the length is 32 and the value displayed is 31.

The value of the id-data-presentation field denotes the IPv4 address or IPv6 prefix

details. If the fully qualified domain name (FQDN) is specified insteadof the address

for the remote peer of the IPsec association, it is displayed instead of the address

details.

• The “Understanding Aggregated Mulitservices Interfaces” and the “Example:

Configuring an Aggregated Mulitservices Interface (AMS)” topics in the Services

Interface Configuration Guide incorrectly state that whenmember-failure-options is

not configured, the default behavior is to redistribute the traffic among the available

interfaces. The correct behavior is that when themember-failure-options statement

is not configured, the default behavior is to dropmember trafficwith a rejoin timeout

of 120 seconds.

• The functionality to log the cflowd records in a log file before they are exported to a

cflowd server (by including the local-dump statement at the [edit forwarding-options

sampling instance instance-name family (inet |inet6 |mpls)output flow-serverhostname]

hierarchy level) is not supportedwhenyouconfigure inline flowmonitoring (by including

the inline-jflow statement at the [edit forwarding-options sampling instance

instance-name family inet output] hierarchy level).

• The following information regarding the interoperationofFTPALGandaddress-pooling

paired features is missing from the "ALG Descriptions" topic of the "Application

Properties" chapter:



OnMS-MPCs andMS-MICs, for passive FTP to work properly without FTP application

layer gateway (ALG) enabled (by not specifying the application junos-ftp statement

at the [edit services stateful-firewall rule rule-name term term-name from] and the [edit

services nat rule rule-name term term-name from] hierarchy levels), youmust enable

the address pooling paired (APP) functionality enabled (by including the

address-pooling statement at the [edit servicesnat rule rule-name term term-name then

translated] hierarchy level). Such a configuration causes the data and control FTP

sessions to receive the same NAT address.

Standards Reference

• The “Supported FlowMonitoring and Discard Accounting Standards” topic fails to

mention the following additional information:

On MX Series routers, Junos OS partially supports the following RFCs:

• RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the

Exchange of IP Traffic Flow Information

• RFC 5102, Information Model for IP Flow Information Export

Subscriber Management Feature Guide

• In the Junos OS Subscriber Management Feature Guide, the fail-over-within-preference

statement at the [edit services l2tp] hierarchy level is incorrectly spelled. The correct

spelling for this statement is failover-within-preference.

• The Junos OS Release 13.3 Subscriber Management Feature Guide fails to include the

new user@domain option for filtering AAA, L2TP, and PPP traces by subscriber. See

the feature description in these Release Notes titled Support for filtering trace results

by subscribers for AAA, L2TP, and PPP for information about using this option.

• The “Example: HTTPServiceWithin aService Set” topic in theSubscriberManagement

Feature Guide erroneously describes how to configure captive portal content delivery

rules in service sets.

Use the followingprocedure to configure captiveportal content delivery rules in service

sets:

1. Define one or more rules with the rule rule-name statement at the [edit services

captive-portal-content-delivery]hierarchy level. In each rule youspecify oneormore

terms to match on an application, destination address, or destination prefix list;

where the match takes place; and actions to be taken when thematch occurs,

2. (Optional) Define one or more rule sets by listing the rules to be included in the set

with the rule-set rule-set-name statement at the [edit services

captive-portal-content-delivery] hierarchy level.

3. Configure a captive portal content delivery profile with the profile profile-name

statement at the [edit services captive-portal-content-delivery] hierarchy level.

4. In the profile, specify a list of rules with the cpcd-rules [rule-name] statement or a

list of rule setswith the cpcd-rule-sets [rule-set-name] statement. Both statements



areat the [editservicescaptive-portal-content-deliveryprofileprofile-name]hierarchy

level.

5. Associate theprofilewithaservicesetwith thecaptive-portal-content-delivery-profile

profile-name statement at the [edit services service-set service-set-name] hierarchy

level.

• The “LAC Tunnel Selection Overview” topic in the Junos OS Subscriber Management

FeatureGuide incorrectly describes thecurrentbehavior for failover betweenpreference

levels. The topic states that when the tunnels at every preference level have a

destination in the lockout state, the LAC cycles back to the highest preference level

andwaits for the lockout time for adestinationat that level to expire before attempting

to connect and starting the process over.

In fact, the current behavior in this situation is that from the tunnels present at the

lowest level of preference (highest preference number), the LAC selects the tunnel

that has the destinationwith the shortest remaining lockout time. The LAC ignores the

lockout and attempts to connect to the destination.

• The Subscriber Management Scaling Values (XLS) spreadsheet previously reported

that 64,000 PPPoE subscribers are supported per interface for Junos OS Release 12.3

and subsequent releases. In fact, the chassis supports 128,000 PPPoE subscribers

beginning in Junos OS Release 12.3.

You can access the latest version of the Subscriber Management Scaling Values (XLS)

spreadsheet fromtheDownloadsboxat JunosOSSubscriberManagementandServices

Library.



http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/subscriber-access/index.html

http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/subscriber-access/index.html

System LogMessages Reference

• The formats of theMSVCS_LOG_SESSION_OPENandMSVCS_LOG_SESSION_CLOSE

system logmessages in the "MSVCS System Log Messages" chapter are incorrectly

specified. The following is the correct and complete format of the

MSVCS_LOG_SESSION_OPEN and MSVCS_LOG_SESSION_CLOSE system log

messages:

App: application, source-interface-name fpc/pic/port\address in hexadecimal format

source-address:source-port source-nat-information ->

destination-address:destination-port destination-nat-information (protocol-name)

hh:mm:ss.milliseconds protocol-name (tos tos-bit-value, ttl ttl-value, id id-number,

offset offset-value, flags [ip-flag-type], proto protocol- name (protocol-id), length

number)

Unified ISSU SystemRequirements

• In Junos OS Release 13.3, the “Unified ISSU System Requirements” topic in the Junos

OS High Availability Feature Guide for Routing Devices incorrectly states in Table 2:

Unified ISSU Protocol SupportIU PROTOCOL SUPPORT that an MX Series Virtual

Chassis supports unified ISSU in Junos OS Release 12.2 and later releases. In fact, an

MX Series Virtual Chassis supports unified ISSU in Junos OS Release 14.1 and later

releases.

[See Unified ISSU System Requirements.]

Virtual Chassis support onMX104 routers

• In Junos OS Release 13.3, the Software feature support (MX104) feature description in

the Release Notes: Junos®OS Release 13.3R1 for the EX Series, M Series, MX Series, PTX

Series, and TSeries incorrectly states in the Layer 2 features section that Virtual Chassis

is supported on MX104 routers. Virtual Chassis is not supported on MX104 routers.

VPLS Feature Guide for Routing Devices

• The following information regarding the working of firewall filters and policers with

MAC addresses applies to the "Configuring Firewall Filters and Policers for VPLS "

topic:

The behavior of firewall filters processing with MAC addresses differs between DPCs

and MPCs. On MPCs, interface filters are always applied before MAC learning occurs.

The input forwarding table filter is applied after MAC learning is completed. However,

onDPCs,MAC learningoccurs independentlyof theapplicationof filters. If theCE-facing

interface of the PE where the firewall filter is applied is an MPC, then the MAC entry

times out and is never learned again. However, if the CE-facing interface of the PE

where the firewall filter is applied is an DP, then the MAC entry is not timed out and if

the MAC address entry is manually cleared, it is relearned.

VPWS Feature Guide for Routing Devices



http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/requirements/issu-system-requirements.html

• In JunosOSRelease 13.3, the Layer 2Circuits FeatureGuide for RoutingDeviceshasbeen

renamed VPWS Feature Guide for Routing Devices. VPWS content has been added to

this guide, and has been removed from the VPLS Feature Guide for Routing Devices.










This sectioncontains theprocedure toupgrade JunosOS,and theupgradeanddowngrade

policies for JunosOS for theMSeries,MXSeries, andTSeries. Upgrading or downgrading

JunosOScan take several hours, depending on the size and configuration of the network.

• Basic Procedure for Upgrading to Release 13.3 on page 125

• Upgrade and Downgrade Support Policy for Junos OS Releases on page 128

• Upgrading a Router with Redundant Routing Engines on page 128

• Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS

Release 10.1 on page 129

• Upgrading the Software for a Routing Matrix on page 130

• Upgrading Using Unified ISSU on page 131

• Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and

NSR on page 132

• Downgrading from Release 13.3 on page 133

• Changes Planned for Future Releases on page 133

Basic Procedure for Upgrading to Release 13.3

In order to upgrade to Junos OS 10.0 or later, youmust be running Junos OS 9.0S2, 9.1S1,

9.2R4, 9.3R3, 9.4R3, 9.5R1, or later minor versions, or youmust specify the no-validate

option on the request system software install command.

When upgrading or downgrading Junos OS, always use the jinstall package. Use other

packages (such as the jbundle package) only when so instructed by a Juniper Networks

support representative. For information about the contents of the jinstall package and

details of the installation process, see the Installation and Upgrade Guide.




NOTE: With JunosOSRelease 9.0 and later, the compact flash diskmemoryrequirement for Junos OS is 1 GB. For M7i andM10i routers with only 256MBmemory, see the Customer Support Center JTAC Technical BulletinPSN-2007-10-001 athttps://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001

&actionBtn=Search

NOTE: Before upgrading, back up the file system and the currently activeJunos OS configuration so that you can recover to a known, stableenvironment in case the upgrade is unsuccessful. Issue the followingcommand:

user@host> request system snapshot

The installation process rebuilds the file system and completely reinstallsJunos OS. Configuration information from the previous software installationis retained, but the contents of log files might be erased. Stored files on therouting platform, such as configuration templates and shell scripts (the onlyexceptions are the juniper.conf and ssh files) might be removed. To preserve

the stored files, copy them to another system before upgrading ordowngrading the routing platform. For more information, see the Junos OS

Administration Library for Routing Devices.



http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/system-basics/


Thedownloadand installationprocess for JunosOSRelease 13.3 isdifferent fromprevious

Junos OS releases.

Before upgrading to 64-bit Junos OS, read the instruction on the following pages:

• To check Routing Engine compatibility, see Supported Routing Engines by Router.

• To read the upgrade instructions, see Upgrading to 64-bit Junos OS.

1. Using aWeb browser, navigate to the All Junos Platforms software download URL on

the Juniper Networks webpage:

http://www.juniper.net/support/downloads/

2. Select the name of the Junos platform for the software that you want to download.

3. Select the release number (the number of the software version that you want to

download) from the Release drop-down list to the right of the Download Software

page.

4. Select the Software tab.

5. In the Install Package section of the Software tab, select the software package for the

release.

6. Log in to the Juniper Networks authentication system using the username (generally

your e-mail address) and password supplied by Juniper Networks representatives.

7. Review and accept the End User License Agreement.

8. Download the software to a local host.

9. Copy the software to the routing platform or to your internal software distribution

site.

10. Install the new jinstall package on the routing platform.

NOTE: We recommend that you upgrade all software packages out ofband using the console because in-band connections are lost during theupgrade process.

Customers in the United States and Canada, use the following command:

user@host> request system software add validate rebootsource/jinstall-13.3R41-domestic-signed.tgz

All other customers, use the following command:

user@host> request system software add validate rebootsource/jinstall-13.3R41-export-signed.tgz

Replace sourcewith one of the following values:

• /pathname—For a software package that is installed from a local directory on the

router.

• For software packages that are downloaded and installed from a remote location:

• ftp://hostname/pathname



http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/routing-engine-m-mx-t-series-support-by-chassis.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/64-bit-junos-upgrading.html


• http://hostname/pathname

• scp://hostname/pathname (available only for Canada and U.S. version)

The validate option validates the software package against the current configuration

as a prerequisite to adding the software package to ensure that the router reboots

successfully. This is the default behavior when the software package being added is

a different release.

Adding the reboot command reboots the router after the upgrade is validated and

installed. When the reboot is complete, the router displays the login prompt. The

loading process can take 5 to 10minutes.

Rebooting occurs only if the upgrade is successful.

NOTE: After you install a Junos OS Release 13.3 jinstall package, you cannot

issue the requestsystemsoftwarerollbackcommandto return to thepreviously

installed software. Instead youmust issue the request system software add

validate command and specify the jinstall package that corresponds to the

previously installed software.

Upgrade and Downgrade Support Policy for Junos OS Releases

Support for upgrades and downgrades that spanmore than three Junos OS releases at

a time is not provided, except for releases that are designated as Extended End-of-Life

(EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can

upgrade directly from one EEOL release to the next EEOL release even though EEOL

releases generally occur in increments beyond three releases.

You can upgrade or downgrade to the EEOL release that occurs directly before or after

the currently installed EEOL release, or to twoEEOL releases before or after. For example,

Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from Junos

OS Release 10.0 to Release 10.4 or even from Junos OS Release 10.0 to Release 11.4.

However, you cannot upgrade directly from a non-EEOL release that is more than three

releases ahead or behind. For example, you cannot directly upgrade from Junos OS

Release 10.3 (a non-EEOL release) to Junos OS Release 11.4 or directly downgrade from

Junos OS Release 11.4 to Junos OS Release 10.3.

To upgrade or downgrade fromanon-EEOL release to a releasemore than three releases

before or after, first upgrade to the next EEOL release and then upgrade or downgrade

from that EEOL release to your target release.

For more information on EEOL releases and to review a list of EEOL releases, see


Upgrading a Router with Redundant Routing Engines

If the router has two Routing Engines, perform a Junos OS installation on each Routing

Engine separately to avoid disrupting network operation as follows:




1. Disable graceful Routing Engine switchover (GRES) on themaster Routing Engine

and save the configuration change to both Routing Engines.

2. Install the new Junos OS release on the backup Routing Engine while keeping the

currently running software version on themaster Routing Engine.

3. After making sure that the new software version is running correctly on the backup

RoutingEngine, switchover to thebackupRoutingEngine toactivate thenewsoftware.

4. Install the new software on the original master Routing Engine that is now active as

the backup Routing Engine.

For the detailed procedure, see the Installation and Upgrade Guide.

Upgrading JuniperNetworkRoutersRunningDraft-RosenMulticastVPN to JunosOS Release 10.1

In releases prior to Junos OS Release 10.1, the draft-rosenmulticast VPN feature

implements the unicast lo0.x address configured within that instance as the source

address used to establish PIM neighbors and create the multicast tunnel. In this mode,

the multicast VPN loopback address is used for reverse path forwarding (RPF) route

resolution to create the reverse path tree (RPT), or multicast tunnel. Themulticast VPN

loopback address is also used as the source address in outgoing PIM control messages.

In Junos OS Release 10.1 and later, you can use the router’s main instance loopback

(lo0.0) address (rather than themulticast VPN loopback address) to establish the PIM

state for the multicast VPN. We strongly recommend that you perform the following

procedure when upgrading to Junos OS Release 10.1 if your draft-rosenmulticast VPN

network includes both Juniper Network routers and other vendors’ routers functioning

as provider edge (PE) routers. Doing so preservesmulticast VPNconnectivity throughout

the upgrade process.

Because JunosOSRelease 10.1 supportsusing the router’smain instance loopback (lo0.0)

address, it is no longer necessary for the multicast VPN loopback address to match the

main instance loopback adddress lo0.0 to maintain interoperability.

NOTE: Youmight want tomaintain amulticast VPN instance lo0.x address

to use for protocol peering (such as IBGP sessions), or as a stable routeridentifier, or to support the PIM bootstrap server function within the VPNinstance.

Complete the following steps when upgrading routers in your draft-rosenmulticast VPN

network to Junos OS Release 10.1 if you want to configure the routers’s main instance

loopback address for draft-rosenmulticast VPN:

1. Upgrade all M7i and M10i routers to Junos OS Release 10.1 before you configure the

loopback address for draft-rosen Multicast VPN.

NOTE: Do not configure the new feature until all theM7i andM10i routersin the network have been upgraded to Junos OS Release 10.1.




2. After you have upgraded all routers, configure each router’s main instance loopback

address as the source address formulticast interfaces. Include thedefault-vpn-source

interface-name loopback-interface-name] statement at the [edit protocols pim]

hierarchy level.

3. After you have configured the router’s main loopback address on each PE router,

delete the multicast VPN loopback address (lo0.x) from all routers.

We also recommend that you remove themulticast VPN loopback address from all

PE routers from other vendors. In Junos OS releases prior to 10.1, to ensure

interoperability with other vendors’ routers in a draft-rosenmulticast VPN network,

you had to perform additional configuration. Remove that configuration from both

the JuniperNetworks routers and the other vendors’ routers. This configuration should

beon JuniperNetworks routers andon theother vendors’ routerswhere youconfigured

the lo0.mvpnaddress ineachVRF instanceas thesameaddressas themain loopback

(lo0.0) address.

This configuration is not requiredwhen you upgrade to Junos OS Release 10.1 and use

themain loopback address as the source address for multicast interfaces.

NOTE: Tomaintain a loopback address for a specific instance, configurea loopback address value that does notmatch themain instance address(lo0.0).

For more information about configuring the draft-rosen Multicast VPN feature, see the

Multicast Protocols Feature Guide for Routing Devices.

Upgrading the Software for a RoutingMatrix

A routing matrix can be either a TXMatrix router as the switch-card chassis (SCC) or a

TXMatrix Plus router as the switch-fabric chassis (SFC). By default, when you upgrade

software for a TXMatrix router or a TXMatrix Plus router, the new image is loaded onto

the TXMatrix or TX Matrix Plus router (specified in the Junos OS CLI by using the scc or

sfc option) and distributed to all line-card chassis (LCCs) in the routingmatrix (specified

in the Junos OS CLI by using the lcc option). To avoid network disruption during the

upgrade, ensure the following conditions before beginning the upgrade process:

• Aminimumof freedisk spaceandDRAMoneachRoutingEngine.Thesoftwareupgrade

will fail on any Routing Engine without the required amount of free disk space and

DRAM.Todetermine theamountofdisk spacecurrentlyavailableonallRoutingEngines

of the routing matrix, use the CLI show system storage command. To determine the

amount of DRAM currently available on all the Routing Engines in the routing matrix,

use the CLI show chassis routing-engine command.

• Themaster Routing Engines of the TXMatrix or TX Matrix Plus router (SCC or SFC)

and all LCCs connected to the SCC or SFC are all re0 or are all re1.

• The backup Routing Engines of the TXMatrix or TX Matrix Plus router (SCC or SFC)

and all LCCs connected to the SCC or SFC are all re1 or are all re0.



http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/config-guide-multicast/config-guide-multicast.html

• All master Routing Engines in all routers run the same version of software. This is

necessary for the routing matrix to operate.

• All master and backup Routing Engines run the same version of software before

beginning the upgrade procedure. Different versions of the Junos OS can have

incompatible message formats especially if you turn on GRES. Because the steps in

the process include changing mastership, running the same version of software is

recommended.

• For a routing matrix with a TXMatrix router, the same Routing Engine model is used

within a TXMatrix router (SCC) and within a T640 router (LCC) of a routing matrix.

For example, a routing matrix with an SCC using two RE-A-2000s and an LCC using

two RE-1600s is supported. However, an SCC or an LCC with two different Routing

Engine models is not supported. We suggest that all Routing Engines be the same

model throughout all routers in the routing matrix. To determine the Routing Engine

type, use the CLI show chassis hardware | match routing command.

• For a routing matrix with a TXMatrix Plus router, the SFC contains twomodel

RE-DUO-C2600-16G Routing Engines, and each LCC contains twomodel

RE-DUO-C1800-8G or RE-DUO-C1800-16G Routing Engines.

BEST PRACTICE: Make sure that all master Routing Engines are re0 and allbackup Routing Engines are re1 (or vice versa). For the purposes of thisdocument, themaster Routing Engine is re0 and the backup Routing Engineis re1.

To upgrade the software for a routing matrix, perform the following steps:


(re0) and save the configuration change to both Routing Engines.

2. Install the new Junos OS release on the backup Routing Engine (re1) while keeping

the currently running software version on themaster Routing Engine (re0).

3. Load the new JunosOSon the backupRouting Engine. Aftermaking sure that the new

software version is running correctly on the backup Routing Engine (re1), switch

mastership back to the original master Routing Engine (re0) to activate the new

software.

4. Install the new software on the new backup Routing Engine (re0).

For thedetailedprocedure, see theRoutingMatrixwithaTXMatrixRouterDeploymentGuide

or the Routing Matrix with a TXMatrix Plus Router Deployment Guide.

Upgrading Using Unified ISSU

Unified in-service softwareupgrade (ISSU)enables you toupgradebetween twodifferent

Junos OS releases with no disruption on the control plane and with minimal disruption

of traffic. Unified in-service software upgrade is only supported by dual Routing Engine

platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active

routing (NSR)must be enabled. For additional information about using unified in-service

software upgrade, see the High Availability Feature Guide for Routing Devices.



http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/solutions/routing-matrix/routing-matrix.pdf

http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/solutions/routing-matrix-tx-matrix-plus/index.pdf

http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/config-guide-high-availability/high-availability.html

Upgrading from JunosOSRelease 9.2 or Earlier on aRouter Enabled for BothPIMand NSR

Junos OS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the

following PIM features are not currently supportedwith NSR. The commit operation fails

if the configuration includes both NSR and one or more of these features:

• Anycast RP

• Draft-Rosenmulticast VPNs (MVPNs)

• Local RP

• Next-generation MVPNs with PIM provider tunnels

• PIM join load balancing

Junos OS Release 9.3 introduced a new configuration statement that disables NSR for

PIM only, so that you can activate incompatible PIM features and continue to use NSR

for the other protocols on the router: the nonstop-routing disable statement at the [edit

protocolspim]hierarchy level. (Note that this statementdisablesNSR for all PIM features,

not only incompatible features.)

If neitherNSRnorPIM is enabledon the router tobeupgradedor if oneof theunsupported

PIM features is enabled but NSR is not enabled, no additional steps are necessary and

you can use the standard upgrade procedure described in other sections of these

instructions. If NSR is enabled and no NSR-incompatible PIM features are enabled, use

the standard reboot or ISSU procedures described in the other sections of these

instructions.

Because the nonstop-routing disable statement was not available in Junos OS Release

9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to

be upgraded from Junos OS Release 9.2 or earlier to a later release, youmust disable

PIM before the upgrade and reenable it after the router is running the upgraded Junos

OS and you have entered the nonstop-routing disable statement. If your router is running

Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR

orPIM–simplyuse thestandard rebootor ISSUproceduresdescribed in theother sections

of these instructions.

To disable and reenable PIM:

1. On the router running Junos OS Release 9.2 or earlier, enter configuration mode and

disable PIM:

[edit]

user@host# deactivate protocols pimuser@host# commit

2. Upgrade to Junos OS Release 9.3 or later software using the instructions appropriate

for the router type. You caneither use the standardprocedurewith reboot or use ISSU.

3. After the router reboots and is running the upgraded Junos OS, enter configuration

mode, disablePIMNSRwith thenonstop-routingdisable statement, and then reenable

PIM:



[edit]

user@host# set protocols pim nonstop-routing disableuser@host# activate protocols pimuser@host# commit

Downgrading fromRelease 13.3

To downgrade from Release 13.3 to another supported release, follow the procedure for

upgrading, but replace the 13.3 jinstall package with one that corresponds to the

appropriate release.

NOTE: Youcannot downgrademore than three releases. For example, if yourrouting platform is running Junos OS Release 11.4, you can downgrade thesoftware to Release 10.4 directly, but not to Release 10.3 or earlier; as aworkaround, you can first downgrade to Release 10.4 and then downgradeto Release 10.3.

For more information, see the Installation and Upgrade Guide.

Changes Planned for Future Releases

The following are changes planned for future releases.

Routing Protocols

• Change in Junos OS support for the BGPMonitoring Protocol (BMP)—In Junos OSRelease 13.3and later, thecurrently supportedversionofBMP,BMPversion 1, asdefined

in Internet draft draft-ietf-grow-bmp-01, is planned to be replaced with BMP version

3, as defined in Internet draft draft-ietf-grow-bmp-07.txt. Junos OS can support only

one of these versions of BMP in a release. Therefore, Junos OS Release 13.2 and earlier

releases will continue to support BMP version 1, as defined in Internet draft

draft-ietf-grow-bmp-01. Junos OS Release 13.3 and later support only the updated

BMP version 3 defined in Internet draft draft-ietf-grow-bmp-07.txt. This also means

thatbeginning in JunosOSRelease 13.3,BMPversion3configurationsarenotbackwards

compatible with BMP version 1 configurations from earlier Junos OS releases.

• Removalofsupport forproviderbackbonebridging(MXSeries routers) fromRelease14.1—Starting with Junos OS Release 14.1, the provider backbone bridging (PBB)capability is disabled and not supported on MX Series routers. The pbb-options

statementand its substatementsat the [edit routing-instances routing-instance-name]

hierarchy level and the pbb-service-options statement and its substatements at the

[edit routing-instances routing-instance-name service-groups service-group-name]

hierarchy level are no longer available for configuring customer and provider routing

instances for PBB. When you upgrade MX Series routers running Junos OS Releases

12.3, 13.2, or 13.3 to JunosOSRelease 14.1 and if your deployment contains PBB settings

in configuration files, the configuration files after the upgrade need to bemodified to

remove the PBB-specific attributes because PBB is not supported in Release 14.1 and

later.

[See Provider Backbone Bridging Feature Guide for Routing Devices.]




http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/layer-2/pbb-mx-series.html











special compatibility guidelineswith the release, see theHardwareGuideand the Interface

Module Reference for the product.

To determine the features supported onM Series, MX Series, and T Series devices in this

release, use the Juniper Networks Feature Explorer, a Web-based application that helps

you to explore and compare Junos OS feature information to find the right software

release and hardware platform for your network. Find Feature Explorer at:










Junos OS Release Notes for PTX Series Packet Transport Routers

These release notes accompany Junos OS Release 13.3R4 for the PTX Series. They

describe new and changed features, limitations, and known and resolved problems in

the hardware and software.












OS Release 13.3R4 for the PTX Series.









Hardware

• PTX3000PacketTransportRouter—TheJuniperNetworksPTX3000PacketTransportRouter provides 10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet

interfaces for large networks and network applications, such as those supported by

ISPs. The router accommodates up to eight Flexible PIC Concentrators (FPCs), each

of which supports one PIC. The compact design of the PTX3000 router allows up to

four chassis to be installed back-to-back in a single four-post rack. The PTX3000

router can be configured with single-phase AC or DC power supply modules.

[See the PTX3000 Packet Transport Router Hardware Guide.]

• CFP-GEN2-CGE-ER4 and CFP-GEN2-100GBASE-LR4 (PTX5000)—TheCFP-GEN2-CGE-ER4 transceiver (part number: 740-049763) provides a duplex LC

connector and supports the 100GBASE-ER4 optical interface specification and

monitoring. The CFP-GEN2-100GBASE-LR4 transceiver (part number: 740-047682)


Junos OS Release Notes for PTX Series Packet Transport Routers


http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/ptx-series/ptx3000/index.html

provides a duplex LC connector and supports the 100GBASE-LR4 optical interface

specificationandmonitoring. Starting in JunosOSRelease 13.3, the “GEN2”optics have

been redesigned with newer versions of internal components for reduced power

consumption. The following interface module supports the CFP-GEN2-CGE-ER4 and

CFP-GEN2-100GBASE-LR4transceivers. Formore informationabout interfacemodules,

see the Interface Module Reference for your router.

• 100-Gigabit Ethernet PIC with CFP (model number:

P1-PTX-2-100GE-CFP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3R1, and

later






• Support for strict-priority scheduling (PTX Series)—Beginning with Junos OS Release

13.3, interfaces on PTX Series routers support strict-priority scheduling. Configured

queues are processed in strict-priority order. Within the guaranteed region, multiple

CoS queues that compete in the same hardware-based priority level are selected

based on the packet round-robin algorithm, while within the excess region, selection

is based on theWRR algorithm. The queues receive equal share when they send the

same packet size. Otherwise, the queues receive shares proportional to the respective

packet sizes sent. To enable configuration of strict-priority scheduling for a physical

interface on a PTX Series router, include the strict-priority-scheduler statement in the

traffic control profile associated with the interface.

[See Understanding Scheduling on PTX Series Routers.]

General Routing

• Nonstop active routing support for logical systems (PTX Series)—Starting in Junos

OSRelease 13.3, this featureenablesnonstopactive routing support for logical systems

using the nonstop-routing option under the [edit logical-systems logical-system-name

routing-options] hierarchy. As a result of extending nonstop active routing support for

logical systems, the logical-systems argument has been appended in some show

operational commands to allow display of status, process, and event details.


• Nonstop active routing support for BGP addpath (PTX Series)—Beginning in JunosOS Release 13.3, nonstop active routing support for BGP addpath is available on the

PTX Series. Nonstop active routing support is enabled for the BGP addpath feature.

After the nonstop active routing switchover, addpath-enabled BGP sessions do not

bounce. The secondary Routing Engine maintains the addpath advertisement state

before the nonstop active routing switchover.


• FPC self-healing (PTX Series)—Starting in Junos OS Release 13.3, PTX Series routersallow you to configure Packet Forwarding Engine-related error levels (fatal, major, or

minor) and the actions to perform (alarm, disable-pfe, or log) when a specified

threshold is reached.Previously, Packet ForwardingEngine-relatederrorswoulddisable

the FPC. Using this commandPacket Forwarding Engine errors can be isolated thereby

reducing the need for a field replacement. This command is available at the [edit

chassis fpc slot-number] and [edit chassis] hierarchy levels.

• 2-port 100-Gigabit DWDMOTNPIC (PTX3000)—Beginning with Junos OS Release13.3, the 2-port 100-Gigabit dense wavelength division multiplexing (DWDM) optical

transport network (OTN) PIC is supported by Type 5 FPCs on PTX3000 routers. The

100-Gigabit DWDMOTN PIC supports the following features:

• Transparent transport of two 100-Gigabit Ethernet signals with OTU4 framing

• ITU-standard OTN performancemonitoring and alarmmanagement



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/cos-strict-scheduling-ptx.html

• Dual polarization quadrature phase shift keying (DP-QPSK)modulation and

soft-decision forwarderror correction (SD-FEC) for longhaul andmetroapplications

You can use SNMP tomanage the PIC based on RFC 3591,Managed Objects for the

Optical Interface Type.

[See 100-Gigabit Ethernet OTNOptions Configuration Overview.]

• Pre-FECBERfast reroute(PTX3000)—Starting in JunosOSRelease 13.3, the 100-GbpsDWDMOTN PIC (P1-PTX-2-100G-WDM) supports pre-forward error correction

(pre-FEC) bit error rate (BER) monitoring as a condition for MPLS fast reroute (FRR).

Pre-FEC BER FRR uses pre-FEC BER as an indication of the condition of an optical

transport network (OTN) link. When the pre-FEC BER degrade threshold is reached,

thePIC stops forwarding packets to the remote interface and raises an interface alarm.

Ingress packets continue to be processed. When Pre-FEC BER FRR is used with MPLS

FRR or another link protection method, traffic is then rerouted to a different interface.

You can optionally enable backward FRR to inject local pre-FEC status into the

transmitted OTN frames, notifying the remote interface. The remote interface then

reroutes traffic to a different interface.When you use pre-FEC BER FRR and backward

FRR, notification of signal degradation and rerouting of traffic can occur in less time

than through a Layer 3 protocol.

[See 100-Gigabit Ethernet OTNOptions Configuration Overview.]

• Support for configuring interface alias names (PTX Series)—Beginning in Junos OSRelease 13.3, you can configure a textual description of a physical interface or the

logical unit of an interface to be the alias of an interface name. If you configure an

interface alias, this alias name is displayed in the output of the show interfaces

commands instead of the interface name. Also, in the output of all of the show and

operational mode commands that display the interface names, the alias name is

displayed instead of the interface name if you configure the alias name. It has no effect

on theoperationof the interfaceon the router or switch.Youcanuse thealias statement

at the [edit interfaces interface-name], [edit interfaces interface-name unit

logical-unit-number], and [edit logical-systems logical-system-name interfaces

interface-name unit logical-unit-number] hierarchy levels to specify an interface alias.

[See Interface Alias NameOverview]

• Support for active flowmonitoring version 9 (PTX5000 routers withCSE2000)—Starting with Junos OS Release 13.3, Carrier-Grade Service Engine(CSE2000) supports active flowmonitoring version 9 on PTX5000 routers.

TheCSE2000 is tethered toaPTX5000router toenableactive flowmonitoringversion

9.Active flowmonitoring version9 supports IPV4,MPLS, and IPV6 templates to collect

a set of sampled flows and send the records to a specified host.

• SFPP-10G-CT50-ZR (PTX Series)—Beginning in Junos OS Release 13.3R3, theSPFF-10G-CT50-ZR tunable transceiver provides a duplex LC connector and supports

the 10GBASE-Z optical interface specification andmonitoring. The transceiver is not

specified as part of the 10-Gigabit Ethernet standard and is instead built according to

Juniper Networks specifications. OnlyWAN-PHY and LAN-PHYmodes are supported.

To configure the wavelength on the transceiver, use thewavelength statement at the



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-100-gigabit-ethernet-otn-options-configuration-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-100-gigabit-ethernet-otn-options-configuration-overview.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-alias-name-overview.html

[edit interfaces interface-name optics-options] hierarchy level. The following interface

module supports the SPFF-10G-CT50-ZR transceiver:

PTX:

• 10-Gigabit Ethernet LAN/WANOTN PIC with SFP+ (model number:

P1-PTX-24-10G-W-SFPP)—Supported in Junos OS Release 13.2R3, 13.3R2, 14.1, and

later



[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications andwavelength.]

• SFPP-10G-ZR-OTN-XT (PTX Series)—Starting with Junos OS Release 13.3R3, theSFPP-10G-ZR-OTN-XTdual-rate extended temperature transceiver provides aduplex

LC connector and supports the 10GBASE-Z optical interface specification and

monitoring. The transceiver is not specified as part of the 10-Gigabit Ethernet standard

and is instead built according to ITU-T and Juniper Networks specifications. The

following interface modules support the SFPP-10G-ZR-OTN-XT transceiver:

PTX:

• 10-Gigabit Ethernet PIC with SFP+ (model number:

P1-PTX-24-10GE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and

later

• 10-Gigabit Ethernet LAN/WANOTN PIC with SFP+ (model number:

P1-PTX-24-10G-W-SFPP)—Supported in JunosOSRelease 12.3R5, 13.2R3, 13.3, and

later



[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications.]

• OTN support for PTX Series—Starting in Junos OS Release 13.3, you can configureOTNmode on 10-Gigabit Ethernet interfaces on PTX Series Packet Transport Routers.

Only the 24-port 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (model number:

P1-PTX-24-10G-W-SFPP) supports OTNmode. The following OTN framingmodes

are supported:

• 10-Gigabit Ethernet LAN-PHY over OTU2e/OTU1e

• 10-Gigabit EthernetWAN-PHY over OTU2

The following forward error correction (FEC) types are supported:

• GFEC (G.709)

• EFEC (G.975.1 I.4)

• UFEC (G.975.1 I.7)

• None




http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/configuration-statement/wavelength-edit-interfaces.html


You canmonitor various transport features like 24-hour bins and transport states by

using the transport-monitoring statement at the [edit interfaces] hierarchy level.

• Support for active flowmonitoring version 9 (PTX3000 routers withCSE2000)—Starting with Junos OS Release 13.3R4, Carrier-Grade Service Engine(CSE2000) supports active flowmonitoring version 9 on PTX3000 routers.

TheCSE2000 is tethered toaPTX3000router toenableactive flowmonitoringversion

9. Active flowmonitoring version 9 supports IPv4,MPLS, and IPv6 templates to collect

a set of sampled flows and send the records to a specified host.


• Support for BFD over child links of AE or LAG bundle (cross-functional PacketForwarding Engine/kernel/rpd) (PTX Series)—Beginning in Junos OS Release 13.3,BFDover child links of anAEor LAGbundle is supportedon thePTXSeries. This feature

provides a Layer 3 BFD liveness detection mechanism for child links of the Ethernet

LAG interface. You can enable BFD to run on individual member links of the LAG to

monitor theLayer 3or Layer 2 forwardingcapabilitiesof individualmember links. These

micro BFD sessions are independent of each other despite having a single client that

manages the LAG interface. To enable failure detection for aggregated Ethernet

interfaces, include the bfd-liveness-detection statement at the [edit interfaces aex

aggregated-ether-options bfd-liveness-detection] hierarchy level.

[See Understanding Independent Micro BFD Sessions for LAG.]

Routing Protocols

• Bidirectional PIM support (PTX5000)—Beginning with Junos OS Release 13.3,bidirectional PIM is supported on the PTX5000. The following caveats are applicable

for the bidrectional PIM configuration on the PTX 5000:

• The PTX5000 can be configured both as a bidirectional PIM rendezvous point and

the source node.

• For the PTX5000, you can configure the auto-rp statement at the [edit protocols

pimrp]or the [edit routing-instances routing-instance-nameprotocolspimrp]hierarchy

level with themapping option, but not the announce option.



http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/bfd-for-lag-overview.html

• The PTX5000 does not support nonstop active routing in Junos OS Release 13.3.

• ThePTX5000does not support unified in-service software upgrade (ISSU) in Junos

OS Release 13.3.


• Unified ISSU support for the 100-Gbps DWDMOTNPIC (PTX5000)—Starting inJunosOSRelease 13.3, the 100-GbpsDWDMOTNPIC(P1-PTX-2-100G-WDM)supports

unified in-service software upgrade (ISSU) onPTX5000 routers. Unified ISSUenables

you to upgrade between two different Junos OS releases with no disruption on the

control plane and with minimal disruption of traffic.

[See Unified ISSU System Requirements.]










of JunosOSstatementsandcommands fromJunosOSRelease 13.3R4 for thePTXSeries.





• In Junos OS Releases 13.2R4, 13.3R2, the interpolated fill level of 0 percent has a drop

probability of 0 percent for weighted random early detection (WRED). In earlier Junos

OS releases, interpolatedWRED can have a nonzero drop probability for a fill level of

0 percent, which can cause packets to be dropped even when the queue is not

congested or the port is not oversubscribed.

• Exporting active flowmonitoring version 9 packets fromCSE2000 to PTX Seriesrouters—Starting with Junos OS Release 13.3R4, active flowmonitoring version 9

records created by CSE2000 are sent back to PTX Series Routers on the 10-Gigabit

Ethernet interface. The PTX Series routers then forward the version 9 flow records to

the version 9 flow server.

In releases before Junos OS 13.3R4, the version 9 records are sent to the version 9 flow

server by means of a separate external collector port. PR985729



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/requirements/issu-system-requirements.html


Routing Protocols

• Junos OSmodifies the default BGP extended community value used for MVPN IPv4

VRF route import (RT-import) to the IANA-standardized value. The behavior of the

mvpn-iana-rt-import statement is nowthedefault. Themvpn-iana-rt-import statement

has been deprecated and should be removed from configurations.


• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in the CLI (PTXSeries)—Junos OS reserves the prefix junos- for the identifiers ofconfigurations defined within the junos-defaults configuration group. User-defined

identifiers cannot start with the string junos-. If you configured user-defined identifiers

using the reserved prefix through a NETCONF or Junos XML protocol session, the

commit would correctly fail. Prior to Junos OS Release 13.3, if you configured

user-defined identifiers through the CLI using the reserved prefix, the commit would

incorrectly succeed. Junos OS Release 13.3 and later releases exhibit the correct

behavior. Configurations that currently contain the reserved prefix for user-defined

identifiers other than junos-defaults configuration group identifiers will now correctly

result in a commit error in the CLI.

• Change in show version command output (PTX Series)—Beginning in Junos OSRelease 13.3, the show version command output includes the new Junos field that

displays the Junos OS version running on the device. This new field is in addition to the

list of installed sub-packages running on the device that also display the Junos OS

version number of those sub-packages. This field provides a consistent means of

identifying the Junos OS version, rather than extracting that information from the list

of installed sub-packages. In the future, the list of sub-packages might not be usable

for identifying the JunosOS version running on the device. This change in outputmight

impact existing scripts that parse information from the show version command.







user@host> show versionHostname: lab Model: ptx5000 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS 64-bit Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...

user@host> show versionHostname: lab Model: ptx5000 JUNOS Base OS boot [12.3R2.5]JUNOS Base OS Software Suite [12.3R2.5]JUNOS 64–bit Kernel Software Suite [12.3R2.5]JUNOS Crypto Software Suite [12.3R2.5]...

[See show version.]




• In all supported Junos OS releases, regular expressions can no longer be configured if

they require more than 64MB of memory or more than 256 recursions for parsing.
















Known Issues

This section lists the known issues in hardware and software in JunosOSRelease 13.3R4.

The identifier following the description is the tracking number in the Juniper Networks

Problem Report (PR) tracking system.


• Forwarding and Sampling on page 144



• MPLS on page 145



Known Issues

Hardware

• CCG configuration change does not reprogram hardware automatically. PR896226


• This PR fixes the issue where output ifIndex being exported as 0. Unless there is a

critical business need, we do not plan to backport the fix to releases earlier than 14.1.

PR964745

General Routing

• "rnh_get_forwarding_nh: RNH type 1 unexpected" kernel error messages observed.

PR866282

• The PTX Series router is not supposed to generate pause frames even if it gets

congestion. The behavior is to drop aggressively if it ever runs out of queuing memory.

PR968803

• When "request system halt" is executed on a PTX Series router, the Routing Engine is

halted, but thePTXSeries routerdoesnotdisplayHaltmessageon theCRAFT-Interface

confirming that the system has halted. PR971303

• With 100GPICequippedonPTXSeriesplatform, the 100G linkmight flapduringunified

in-service software upgrade (ISSU). PR1018281

• For release 13.3R4, traffic loss might be seen on flapping the CE-PE interface on the

PTX platform. Although on using 13.3R4.6 or higher release no traffic loss will be seen

on flapping the access facing interface. PR1026955


• On PTX Series platform, CFP-100G-LR4 and CFP2-100G-LR4 optics report incorrect

"Laser output power" values on all four lanes in cli > show interface diagnostics optics

<intf>. PR1021541

• When changing the speed from 10G to 1Gmultiple times, the ping will not work due to

the serdesnotbeing in the right state. A restart of thepic could fix this issue. PR988663









https://prsearch.juniper.net/971303





MPLS

• The problem is seen in PTX Series routers where the composite next-hops are not

observed for a givenVPNmpls route andhence the show route output commandgives

a truncated value which results in script failure. This may be due to default disabled

l3vpn-cnh in case of transit l3vpn router on PTX Series platform. If Resync blob is not

set, RPD will create indirect next-hop for transit route on PE-PE connection network

on PTX Series. If Resync blob is set, RPD will create composite next-hop for transit

route on PE-PE connection network on PTX Series. Using composite next-hop (cnh)

can help scaled network. However, either indirect (inh) or composite next-hops work

properly in control and forwarding planes. PR1007311


• Filesystem corruption might lead to Routing Engine bootup failure. This problem is

observedwhen directory structure on hard disk (or SSD) is inconsistent. Such a failure

shouldnot result inbootupproblemnormally, butdue to thesoftwarebug, theaffected

Junos OS releases mount /var filesystem incorrectly. The affected platform is PTX.

PR905214








Resolved Issues

This section lists the issues fixed in the Junos OSmain release and themaintenance

releases. The identifier following the description is the tracking number in the Juniper

Networks Problem Report (PR) tracking system.





General Routing

• On PTX Series routers with AE interface, when the PTX is in ingress node for P2MP

LSP, the double traffic rate might be seen. PR987005

• When a large number of IGMP join packets try to reach the router, some IGMP packets

might get dropped. PR1007057


Resolved Issues





MPLS

• On PTX Series platformworking as LSP ingress router, the MPLS auto-bandwidth

feature might cause FPC to wedge condition with all interfaces down. PR1005339


• This PR fixes the issue where output ifIndex was being exported as 0. Unless there is

a critical business need, we do not plan to backport the fix to releases earlier than 14.1.

PR964745

Routing Protocols

• ForbidirectionalPIM, the showmulticaststatistics commanddoesnotdisplay the input

counters. This is because a bidirectional route associates with multiple incoming

interfaces (iif's). The statistics are collectedpermroute, and thepacket for bidirectional

groups might come in from any of the iif's. There is no way to impose the incoming

traffic of the route to one of the iif's. PIM-SM, on the other hand, has only one iif per

mroute, and hence the incoming counters are displayed for all PIM-SM routes.

PR865694



• "delete" or "deactivate" of apply-group defining the entire TACACS or RADIUS

configuration configured under [edit system apply-group <>] does not take a effect

oncommit.Thiscould lead toTACACSorRADIUSbasedauthentication tostill continue

working despite removal (delete/deactivate) of configuration. PR992837

General Routing


937774 is rebooted. This problemwill not be observed during the upgrade to this Junos

OS install. It occurs late enough in the shutdown procedure that it shouldn't interfere

with normal operation. PR956691

• On PTX Series platform, performing Routing Engine switchover might cause flabel

(fabric token) tobeoutof syncbetween themasterRoutingEngineandbackupRouting

Engine, which results in FPC crash. PR981202


• SFP+-10G-ZR (part number = 740-052562) is not fully supported on

P1-PTX-24-10G-W-SFPP pic. Inserting the optic on P1-PTX-24-10G-W-SFPP pic can

cause FPC core on the pic. PR974783

• Sometimes cosd generates a corefile when add/delete a child interface on the LAG

bundle. PR961119












IPv6

• On PTX Series platform, when receiving high rate ipv4/ipv6/mpls packets with TTL

equals 1, the ICMP TTL expired messages are sent back to the sender not according

with the ICMP rate limit settings. PR893129

• PTX Series drops packets containing same source and destination IP due to LAND

attack check. PR934364

MPLS

• In rare scenarios, the routing protocol process can fail to read themesh-group

information from the kernel, which might result in the VPLS connections for that

routing-instance to stay in MI (Mesh-Group ID not available) state. The workaround is

to deactivate/activate the routing-instance. PR892593

• MPLS traceroute does not work with logical router. PR965883

• When issue "traceroutempls rsvp lsp-name" from theMPLS LSP ingress node, if there

are PTX Series routers on the LSP path, PTX Series would not list correct downstream

router's IP in the TLV of the response packet. PR966986


• On PTX Series platform, when a firewall filter hasmany terms, all the termsmight not

work correctly due to incorrect order of terms due to mis-programming. PR973545

VLAN Infrastructure

• Commits less than 3minutes apart with per-vlan-queuing configuration should be

avoided, as this might lead to interrupts or undesirable side-effects. PR897601


Chassis Cluster

• When only one end of an AE link sees LACP timeouts or there is intermittent LACP loss

on the AE link, it does not result in AE flap. PR908059

Dynamic Host Configuration Protocol (DHCP)

• DHCP relay feature doesn't work on PTX3000. PR864601

General Routing

• On PTX Series Packet Transport Routers, we support only 48k longest prefix match

(LPM) routes. If the limit of 48,000 longest prefix match (LPM) routes is exceeded,

the kernel routing table (KRT) queue can be stuck with the error "Longest Prefix

Match(LPM) route limit is exceeded." PR801271

• RPDon thebackupRoutingEnginemight crashwhen it receives amalformedmessage

from themaster. This can occur at high scale with nonstop active routing enabled

when a large flood of updates are being sent to the backup. There is no workaround


Resolved Issues











to avoid the problem, but it is rare and backup RPDwill restart and the systemwill

recover without intervention. PR830057

• While performing GRES, the following error message appears: Feb 24 21:23:57 striker1

license-check[1555]: LIBJNX_REPLICATE_RCP_ERROR: rcp -T

re0:/config/license_revoked.db /config/license_revoked.db.new : rcp:

/config/license_revoked.db: No such file or directory This error is seen when no license

is revoked on themaster Routing Engine. It is safe to ignore as it will not affect any

licensing functionality. PR859151


• Interrupt storm happened when press craft button with "craft-lockout". PR870410

• On the PTX Series, while deactivating or activating a firewall filter that has tcp-flags

in the match condition on a loopback interface (e.g. lo0.0), memory corruption could

occur when the filter configuration is pushed to the Packet Forwarding Engine, or is

removed fromthePacketForwardingEngine, causingall theFPCs tocrashandgenerate

core files. The following is logged by the FPCs a few seconds prior to the failure:

fpc1dfw_match_branch_db_destroy:77filter index 1, dfw0x20bb2a90,match_branch_dbnot empty on filter delete

fpc2dfw_match_branch_db_destroy:77filter index 1,dfw0x205a6340,match_branch_dbnot empty on filter delete

fpc0dfw_match_branch_db_destroy:77filter index 1,dfw0x20471c38,match_branch_dbnot empty on filter delete

PR874512

• FPC crash can be triggered by a SBE event after accessing a protectedmemory region,

as indicated in the following log: "System Exception: Illegal data access to protected

memory!" The DDRmemory monitors SBEs and reports the errors as they are

encountered. After the syslog indicates a corrupted address, the scrubbing logic tries

to scrub that location by reading and flushing out 32-byte cache line containing that

location inanattempt toupdate thatmemory locationwithcorrectdata. If thatmemory

location is read-only, it causes illegal access toprotectedmemoryexceptionas reported

and resets the FPC. The above-mentioned scrubbing logic is not needed because even

if SBE is detected, the data is already corrected by the DDR and CPU has a good copy

of the data to continue its execution path. PR919681

• 100GE interfaces on the PTX Series do not display PCS BIP-8 error counters when

queried from the FPC command showmtip-cgpcs <> errors. PR920439

• USB install failed with 13.3B1-PS.1. PR931231

Layer 2 Features

• In some configurations, the MAC address of an AE bundle would fail to be copied to

its child interfaces. This causes thedestinationMACaddress filter check to fail on those

child interfaces, thus preventing ARP resolution and in turn causing the failure in

establishing new egress LSPs.

The workarounds are identified as the following:

• Issuing "commit full" on the router, or










• Adding AE configuration and child interface configuration as two separate commits:

a. Add AE interface configuration, without adding child interface configuration.

b. Commit.

c. Add the child interface configuration (et interface configurations) for the AE

interface.

d. Commit.

PR901744

MPLS

• In an RSVP P2MP crossover/pass-through scenario, more than one sub-LSP can use

the same PHOP and NHOP. If link protection is enabled in the above-mentioned

scenario,whena 'primary linkup' event is immediately followedbyaPathTearmessage,

disassociation of the routes/nexthops are sequential in nature. When the

routes/nexthops disassociation is in progress, if a sub-LSP receives a path tear/PSB

delete will lead to this core file. PR739375

• When a PTX Series router is a penultimate hop of one P2MP LSP branch and acts as

a transit LSR on another branch for the same P2MP LSP, the MPLS packets going out

from the penultimate hop branchmight be tagged with an incorrect Ethertype field.

PR867246

• RPD (routing-protocol process) generates a core file on receipt of an RESVmessage

with an unexpected next-hop address. To avoid the crash, drop the RESVmessage

with a different next-hop IP address, and then the LSP will time out due to lack of

refresh by the RESVmessage and the session is reset. PR887734

• Changing thepreference onan LSPwas considered a catastrophic event, tearing down

the current path and then re-establishing a new one. This PRmakes the preference

changeminor and only needs a new path to be re-signalled in a make-before-break

manner. PR897182


Resolved Issues






Multicast

• Starting in JunosOSRelease 13.2, PTXSeries routers accept traffic from remote sources

to enable the remote source to be learned and advertised by MSDP so that receivers

in other MSDP areas can join the source. To configure this feature, use the

accept-remote-source configuration statement at the [edit protocols pim interface

interface-name] hierarchy level.

NOTE: On PTX Series routers requiring tunnel services, the PIMaccept-remote-source configuration statement is not supported.

PR891500


• "PowerSupply failure", "PowerSupplyRemoved"or "Fan/BlowerRemoved"messages

and SNMP trap hourly occur. PR860223

• Changing the domain-namedoesn't reflect in DNSquery unless a Commit full is done.

Thisbug inmanagementdaemon(mgd)hasbeen resolvedbyensuringmgdpropagates

the new domain-name to file /var/etc/resolv.conf, so that this can be used for future

DNS queries. PR918552


• BothRoutingEnginesmight crashwhenperforminggracefulRoutingEngine switchover

(GRES)or unified in-service software upgrade (ISSU). The root causeof thepanic here

is the addresses used for internal communication are not taken from the new logical

interfaces in such scenarios. PR851086

• In this case, since the overall package (jinstall) is signed, the underlying component

packagesarenot required tobesignedexplicitly.However the infrastructurewaswritten

in such a way to display a warning message if the component package is not signed.

PR932974


• Processing of a neighbor advertisement can get into an infinite loop in the kernel, given

a special set of events with regard to the Neighbor cache entry state and the incoming

neighbor advertisement. PR756656


















This section lists the errata and changes in Junos OS Release 13.3R4 documentation for

the PTX Series.

• Network Management Administration Guide for Routing Devices on page 151

• VPWS Feature Guide for Routing Devices on page 151

NetworkManagement Administration Guide for Routing Devices

• The syntax of the filter-interfaces statement in the “SNMP Configuration Statement”

section is incorrect. The correct syntax is as follows:

filter-interfaces {all-internal-interfaces;interfaces interface-names{interface 1;interface 2;

}}

[See filter-interfaces.]

VPWS Feature Guide for Routing Devices

• In JunosOSRelease 13.3, the Layer 2Circuits FeatureGuide for RoutingDeviceshasbeen

renamed VPWS Feature Guide for Routing Devices. VPWS content has been added to

this guide, and has been removed from the VPLS Feature Guide for Routing Devices.









This sectioncontains theprocedure toupgrade JunosOS,and theupgradeanddowngrade

policies for Junos OS for the PTX Series. Upgrading or downgrading Junos OS can take

several hours, depending on the size and configuration of the network.

• Upgrading Using Unified ISSU on page 152

• Upgrading a Router with Redundant Routing Engines on page 152

• Basic Procedure for Upgrading to Release 13.3 on page 152



http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/filter-interfaces-edit-snmp.html

Upgrading Using Unified ISSU

Unified in-service softwareupgrade (ISSU)enables you toupgradebetween twodifferent

Junos OS releases with no disruption on the control plane and with minimal disruption

of traffic. Unified in-service software upgrade is only supported by dual Routing Engine

platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active

routing (NSR)must be enabled. For additional information about using unified in-service

software upgrade, see the High Availability Feature Guide for Routing Devices.

Upgrading a Router with Redundant Routing Engines

If the router has two Routing Engines, perform a Junos OS installation on each Routing

Engine separately to avoid disrupting network operation as follows:


and save the configuration change to both Routing Engines.

2. Install the new Junos OS release on the backup Routing Engine while keeping the

currently running software version on themaster Routing Engine.

3. After making sure that the new software version is running correctly on the backup

RoutingEngine, switchover to thebackupRoutingEngine toactivate thenewsoftware.

4. Install the new software on the original master Routing Engine that is now active as

the backup Routing Engine.

For the detailed procedure, see the Installation and Upgrade Guide.

Basic Procedure for Upgrading to Release 13.3

When upgrading or downgrading Junos OS, use the jinstall package. For information

about the contents of the jinstall package and details of the installation process, see the

Installation and Upgrade Guide. Use other packages, such as the jbundle package, only

when so instructed by a Juniper Networks support representative.

NOTE: Backupthe file systemandthecurrentlyactive JunosOSconfigurationbefore upgrading Junos OS. This allows you to recover to a known, stableenvironment if the upgrade is unsuccessful. Issue the following command:

user@host> request system snapshot

NOTE: The installation process rebuilds the file system and completelyreinstalls Junos OS. Configuration information from the previous softwareinstallation is retained, but the contents of log files might be erased. Storedfiles on the router, suchas configuration templatesandshell scripts (theonlyexceptions are the juniper.conf and ssh files),might be removed. To preservethe stored files, copy them to another system before upgrading ordowngrading the routing platform. For more information, see the Junos OS

Administration Library for Routing Devices.



http://www.juniper.net/techpubs/en_US/junos13.3/information-products/pathway-pages/config-guide-high-availability/high-availability.html





NOTE: We recommend that you upgrade all software packages out of bandusing the console because in-band connections are lost during the upgradeprocess.

Thedownloadand installationprocess for JunosOSRelease 13.3 isdifferent fromprevious

Junos OS releases.

1. Using aWeb browser, navigate to the All Junos Platforms software download URLon the Juniper Networks webpage:


2. Select thenameof the JunosOSplatformfor thesoftware that youwant todownload.

3. Select the release number (the number of the software version that you want to

download) from the Release drop-down list to the right of the Download Softwarepage.

4. Select the Software tab.

5. In the Install Package section of the Software tab, select the software package forthe release.

6. Log in to the Juniper Networks authentication system using the username (generally

your e-mail address) and password supplied by Juniper Networks representatives.

7. Review and accept the End User License Agreement.

8. Download the software to a local host.

9. Copy the software to the routing platform or to your internal software distribution

site.

10. Install the new jinstall package on the router.

NOTE: After you install a Junos OS Release 13.3 jinstall package, youcannot issue the request system software rollback command to return tothe previously installed software. Instead youmust issue the requestsystem software add validate command and specify the jinstall packagethat corresponds to the previously installed software.




a different release. Adding the reboot command reboots the router after the upgrade

is validated and installed. When the reboot is complete, the router displays the login

prompt. The loading process can take 5 to 10minutes. Rebooting occurs only if the

upgrade is successful.

Customers in the United States and Canada, use the following command:

user@host> request system software add validate rebootsource/jinstall-13.3R41-domestic-signed.tgz




All other customers, use the following command:

user@host> request system software add validate rebootsource/jinstall-13.3R41-export-signed.tgz

Replace the sourcewith one of the following values:

• /pathname—For a software package that is installed from a local directory on the

router.

• For software packages that are downloaded and installed from a remote location:

• ftp://hostname/pathname

• http://hostname/pathname

• scp://hostname/pathname (available only for Canada and U.S. version)




a different release.

Adding the reboot command reboots the router after the upgrade is validated and

installed. When the reboot is complete, the router displays the login prompt. The

loading process can take 5 to 10minutes.

Rebooting occurs only if the upgrade is successful.

NOTE: After you install a Junos OS Release 13.3 jinstall package, you cannot

issue the requestsystemsoftwarerollbackcommandto return to thepreviously

installed software. Instead youmust issue the request system software add

validate command and specify the jinstall package that corresponds to the

previously installed software.














special compatibility guidelineswith the release, see theHardwareGuideand the Interface

Module Reference for the product.

Todetermine the features supportedonPTXSeriesdevices in this release, use the Juniper

Networks Feature Explorer, a Web-based application that helps you to explore and

compare Junos OS feature information to find the right software release and hardware

platform for your network. Find Feature Explorer at:











Third-Party Components

This product includes third-party components. To obtain a complete list of third-party

components, see Copyright and Trademark Information.

For a list of open source attributes for this Junos OS release, seeOpen Source: Source

Files and Attributions.

FindingMore Information

For the latest, most complete information about known and resolved issues with Junos

OS, see the Juniper Networks Problem Report Search application at:

http://prsearch.juniper.net .

Juniper Networks Feature Explorer is aWeb-based application that helps you to explore

and compare Junos OS feature information to find the correct software release and

hardware platform for your network. Find Feature Explorer at:

http://pathfinder.juniper.net/feature-explorer/.

Juniper Networks Content Explorer is aWeb-based application that helps you explore

Juniper Networks technical documentation by product, task, and software release, and

download documentation in PDF format. Find Content Explorer at:

http://www.juniper.net/techpubs/content-applications/content-explorer/.

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can send your comments to

[email protected], or fill out the documentation feedback form at

https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include

the following information with your comments:

• Document or topic name

• URL or page number

• Software release version (if applicable)

Requesting Technical Support

Technical product support is available through the JuniperNetworksTechnicalAssistance

Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

or are covered under warranty, and need postsales technical support, you can access

our tools and resources online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at

http://www.juniper.net/customers/support/downloads/710059.pdf .



http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/system-basics/system-management-initial-configuration.pdf

http://www.juniper.net/support/downloads/opensource/junos/os.html

http://www.juniper.net/support/downloads/opensource/junos/os.html



http://www.juniper.net/techpubs/content-applications/content-explorer/

mailto:[email protected]?subject=

https://www.juniper.net/cgi-bin/docbugreport/

http://www.juniper.net/customers/support/downloads/710059.pdf

• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

• JTAC Hours of Operation —The JTAC centers have resources available 24 hours a day,

7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online

self-service portal called the Customer Support Center (CSC) that provides youwith the

following features:

• Find CSC offerings: http://www.juniper.net/customers/support/

• Search for known bugs: http://www2.juniper.net/kb/

• Find product documentation: http://www.juniper.net/techpubs/

• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

http://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

Toverify serviceentitlementbyproduct serial number, useourSerialNumberEntitlement

(SNE) Tool located at https://tools.juniper.net/SerialNumberEntitlementSearch/.

Opening a Casewith JTAC

You can open a case with JTAC on theWeb or by telephone.

• Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit us at

http://www.juniper.net/support/requesting-support.html .

If you are reporting a hardware or software problem, issue the following command from

the CLI before contacting support:

user@host> request support information | save filename

To provide a core file to Juniper Networks for analysis, compress the file with the gzip

utility, rename the file to include your company name, and copy it to

ftp.juniper.net/pub/incoming. Then send the filename, along with software version

information (the output of the show version command) and the configuration, to

[email protected]. For documentation issues, fill out the bug report form located at

https://www.juniper.net/cgi-bin/docbugreport/.



http://www.juniper.net/support/warranty/

http://www.juniper.net/customers/support/

http://www2.juniper.net/kb/

http://www.juniper.net/techpubs/

http://kb.juniper.net/

http://www.juniper.net/customers/csc/software/

http://kb.juniper.net/InfoCenter/

http://www.juniper.net/company/communities/

http://www.juniper.net/cm/

https://tools.juniper.net/SerialNumberEntitlementSearch/

http://www.juniper.net/cm/

http://www.juniper.net/support/requesting-support.html

http://www.juniper.net/support/requesting-support.html

mailto:[email protected]?subject=

https://www.juniper.net/cgi-bin/docbugreport/

Revision History

7 October 2014—Revision 3, Junos OS Release 13.3R4– EX Series, M Series, MX Series,

PTX Series, and T Series.

30September2014—Revision2, JunosOSRelease 13.3R4–EXSeries,MSeries,MXSeries,


23September2014—Revision 1, JunosOSRelease 13.3R4–EXSeries,MSeries,MXSeries,


28 August 2014—Revision 7, Junos OS Release 13.3R3– EX Series, M Series, MX Series,










29 July 2014—Revision 2, Junos OS Release 13.3R3– EX Series, M Series, MX Series, PTX

Series, and T Series.

22 July 2014—Revision 1, Junos OS Release 13.3R3– EX Series, M Series, MX Series, PTX


26 June 2014—Revision 6, Junos OS Release 13.3R2– EX Series, M Series, MX Series, PTX


29 May 2014—Revision 5, Junos OS Release 13.3R2– EX Series, M Series, MX Series, PTX








28 April 2014—Revision 1, Junos OS Release 13.3R2– EX Series, M Series, MX Series, PTX


20 March 2014—Revision 5, Junos OS Release 13.3R1– EX Series, M Series, MX Series,




27 February 2014—Revision 4, Junos OS Release 13.3R1– EX Series, M Series, MX Series,


6 February 2014—Revision 3, Junos OS Release 13.3R1– EX Series, M Series, MX Series,


30 January 2014—Revision 2, Junos OS Release 13.3R1– EX Series, M Series, MX Series,


23 January 2014—Revision 1, Junos OS Release 13.3R1– EX Series, M Series, MX Series,


Copyright © 2014, Juniper Networks, Inc. All rights reserved.

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the UnitedStates and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All othertrademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,transfer, or otherwise revise this publication without notice.



Documents

ReleaseNotes:Junos fortheEXSeries,MSeries,MXSeries ... · Hostname: lab Model: ex9208 Junos: ... • OnanEXSeriesswitchthathasboth802.1Xauthentication(dot1x) ... (AAA)(RADIUS)onpage26