junos release notes 13.1

Junos®OS 13.1 Release Notes

Release 13.1R415 April 2014Revision 3

These release notes accompany Release 13.1R4 of the Junos operating system (Junos

OS). They describe device documentation and known problems with the software. For

this release, Junos OS Release 13.1 runs only on Juniper Networks T Series routing

platforms.

For the latest, most complete information about outstanding and resolved issues with

the JunosOSsoftware, see the JuniperNetworksonlinesoftwaredefect searchapplication

at http://prsearch.juniper.net.

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

Web page, which is located at http://www.juniper.net/techpubs/software/junos/.

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

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

New Features in Junos OS Release 13.1 for M Series, MX Series, and T Series

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Junos OS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Changes in Default Behavior and Syntax, and for Future Releases in Junos

OS Release 13.1 for M Series, MX Series, and T Series Routers . . . . . . . . . 31

Changes in Default Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 32

Changes Planned for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Known Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

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

Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1Copyright © 2014, Juniper Networks, Inc.

http://prsearch.juniper.net.

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

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Layer 2 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Multiprotocol Label Switching (MPLS) . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

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

Resolved Issues in Junos OS Release 13.1 for M Series, MX Series, and T

Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Current Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

ErrataandChanges inDocumentation for JunosOSRelease 13.1 forMSeries,

MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

UpgradeandDowngrade Instructions for JunosOSRelease 13.1 forMSeries,

MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Basic Procedure for Upgrading to Release 13.1 . . . . . . . . . . . . . . . . . . . . . 122

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

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

Upgrading Juniper Network Routers Running Draft-Rosen Multicast

VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

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

Upgrading Using ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

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

for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Downgrading from Release 13.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Junos OS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Copyright © 2014, Juniper Networks, Inc.2

Junos OS 13.1 Release Notes

JunosOSReleaseNotesforMSeriesMultiserviceEdgeRouters,MXSeries3DUniversalEdge Routers, and T Series Core Routers

NOTE: The Junos OS release for 13.1 is supported on T Series routers only.Use the 13.1ReleaseNotesandall 13.1 documentationonly forTSeries routers.

MSeries andMXSeries features—The JunosOSRelease 13.1 documentationdescribes someM andMX Series features that will be supported in a 13.1special release. However, the 13.1R3 release and later 13.1Rx releases do notsupport M andMX Series routers.

• New Features in Junos OS Release 13.1 for M Series, MX Series, and T Series

Routers on page 3

• Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release

13.1 for M Series, MX Series, and T Series Routers on page 31

• Known Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series

Routers on page 37

• Resolved Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series

Routers on page 73

• ErrataandChanges inDocumentation for JunosOSRelease 13.1 forMSeries,MXSeries,

and T Series Routers on page 99

• Upgrade andDowngrade Instructions for JunosOSRelease 13.1 forMSeries,MXSeries,


New Features in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

The following features have been added to Junos OS Release 13.1. Following the

description is the title of the manual or manuals to consult for further information:

• Class of Service on page 3

• High Availability on page 7

• Interfaces and Chassis on page 8

• Junos OS XML API and Scripting on page 17

• Subscriber Access Management on page 17

• System Logging on page 29

• User Interface and Configuration on page 30

• VPLS on page 31

Class of Service

• MPLS pseudowire subscriber interfaces are subscriber interfaces over pseudowire

terminations. The pseudowire termination acts as a virtual Ethernet. You can configure

subscriber interfaces native to the physical Ethernet interfaces over the Ethernet-like

interface, thereby creating subscriber services over pseudowire terminations. A


Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, and T Series Core Routers

pseudowire interface resides on a logical tunnel, which uses either Layer 2 circuit

signaling or Layer 2 VPN signaling. Junos OS supports MPLS pseudowire subscriber

interfaces by defining pseudowire services physical interfaces, which represent the

pseudowire and the attachment circuits as described in RFC 3985, PseudoWire

Emulation Edge-to-Edge (PWE3) Architecture. In an edge network, the pseudowire can

represent a single subscriber or multiple subscribers.

Junos OS supports two aspects of CoS for MPLS pseudowire subscriber interfaces.

You can apply CoS rewrite rules and behavior aggregate (BA) classifiers to MPLS

pseudowire subscriber interfaces. In addition,CoSperformsegresshierarchical shaping

towards the subscriber on MPLS pseudowire subscriber interfaces. CoS supports

two-level and three-level hierarchical scheduling configurations for egress shaping on

MPLS pseudowire subscriber interfaces.

TheMPLSpseudowire subscriber interface two-level scheduler configurationeffectively

uses only level 1 and level 3 for each pseudowire. The two-level scheduling hierarchy

is as follows:

• Level 4—Forwarding class-based queues

• Level 3—Pseudowire logical interface

• Level 2—Common/shared level 2 node

• Level 1—Common/shared physical interface of the logical tunnel

You use the two-level scheduling when you havemany pseudowires but you do not

require shaping specific to the subscriber logical interface, for example, when your

configuration is one subscriber per pseudowire interface.

There are two variations of the three-level scheduling hierarchy depending on the

location of the interface set. In both cases, the physical interface on which the logical

tunnel resides is at level 1. The first variation of the three-level scheduling hierarchy is

the pseudowire logical interface over the pseudowire transport logical interface. This

scheduling hierarchy is as follows:


• Level 3—Pseudowire logical interfaces

• Level 2—Pseudowire transport logical interfaces


Youapply the traffic-control profiles atboth thepseudowire transport logical interfaces

(level 2) and the pseudowire logical interfaces (level 3).

The secondvariationof the three-level hierarchical scheduling is thepseudowire logical

interfaces over the pseudowire logical interface-set. This scheduling hierarchy is as

follows:


• Level 3—Pseudowire logical interfaces

• Level 2—Interface set of the pseudowire logical interfaces




You apply the traffic-control profile at the pseudowire logical interfaces (level 3) and

at the interface-set (level 2) for the pseudowire logical interfaces. This case is most

useful for subscriber edge customers.

•

NOTE: Although documentation for this feature is included in the JunosOSRelease 13.1 documentation, the 13.1R1 release and later 13.1Rx releasesdo not support M Series andMX Series routers.

CoS adjustment control profiles control which applications and algorithms are used

to modify a subscriber’s shaping characteristics. Subscriber shaping characteristics

are configured using the Junos OS CLI or by RADIUSmessages. Adjustment control

profiles enable subscriber shaping characteristics to be adjusted by other applications

like ANCP, PPPoE tags, and RADIUSCoA after a subscriber is instantiated. Adjustment

control profiles are router-wide and apply to both static and dynamic interfaces.

Table 1 on page 5 describes the applications that can perform rate adjustments and

their associated default algorithms.

Table 1: Adjustment Control Profile Applications and Algorithms

DescriptionDefault AlgorithmDefaultPriorityApplication

RADIUS Change Of Authorization (CoA)messages canupdate the subscriber’s attributes (like shaping-rate)after thesubscriber isauthenticatedandQoSparameters(like shaping-rate) are assigned.

Adjust-always1RADIUS-CoA

The ANCP application canmodify the existingshaping-rate for both static and dynamic logicalinterfaces, and static interface sets. By default, ANCPcanoverrideall otherapplications.Theshaping-ratemustbe specified in order to override it.

Adjust-always1ANCP

The PPPoE tag, access-rate-downstream, canmodifythe Junos OS CLI configured shaping-rate value, as wellas the RADIUS shaping-rate value. By default, thesevalues can bemodified by subsequent RADIUS CoAmessagesandANCPactions. Thesevaluesareconveyedin PPPoE Active Discovery Initiation (PADI) discoverypackets.

Adjust-less2PPPoE-Tags

NOTE: The lower the priority value, the higher the priority.

You can configure the algorithm to the following values:

• Adjust-never

• Adjust-always

• Adjust less



• Adjust less than or equal

• Adjust greater

• Adjust greater than or equal

You configure the values for the shaping-rate, overhead-accountingmode,

overhead-accounting frame-mode-bytes, and overhead-accounting cell-mode-bytes

options under either the [edit dynamic-profiles profile-name

class-of-service-traffic-control-profiles profile-name] hierarchy level or the [edit

class-of-service traffic-control-profiles profile-name] hierarchy level. The adjustment

control profile uses the values of these options to adjust the shaping rate for static and

dynamically instantiated subscribers.

You can configure only one adjustment control profile.

• To configure the adjustment control profile:

[edit]user@host#editclass-of-serviceadjustment-control-profilesprofile-nameapplicationapplication-name

user@host# set priority priority algorithm algorithm

Complete this procedure for each application shown in Table 1 on page 5.

• Extends support for fault management (TXMatrix Plus router with 3D SIBs)—TheTXMatrix Plus router with 3D SIBs supports the following fault types:

• SIB fault—Faults related to power failure, voltage, temperature thresholds, access

errors, and polled I/O errors.

• Cable errors—Errors resulting from loss of sight, optical threshold beyond limits,

transmit failure, cyclic redundancy check error, link training error, and link transmit

error. It can also indicate the number of mandatory cables that are not connected,

or in up state for that plane.

• Link errors—Indicate the number of links that are marked faulty because the errors

on them have crossed threshold.

• Destination errors—Indicate the number of destinations that are not reachable over

the fabric plane.

In Junos OS Release 13.1, the following command is introduced for fault monitoring of

optical links:

• show chassis fabric optical-links

Starting with Junos OS Release 13.1, output of the following commands includes

additional information:

• show chassis sibs

• show chassis fabric plane

New system logmessages are also introduced to provide information about faults,

which includes the reason for the faults.

[See show chassis fabric optical-links, show chassis sibs, and show chassis fabric plane.]



http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/command-summary/show-chassis-fabric-optical-links.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/command-summary/show-chassis-sibs.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/command-summary/show-chassis-fabric-plane.html

High Availability

• Support for high availability features (TXMatrix Plus routerwith 3DSIBs)—Startingwith Junos OS Release 13.1, the following high availability features are supported on

all routers in a routing matrix with a TXMatrix Plus router with 3D SIBs:

• Graceful Routing Engine switchover (GRES)—This feature enables a router with

redundant Routing Engines to continue forwarding packets, even if one Routing

Engine fails. GRES preserves interface and kernel information. In case of GRES with

NSR, the control plane is also preserved. During GRES, nearly 75 percent of line rate

worth of traffic per Packet Forwarding Engine remains uninterrupted during GRES.

• Nonstopactive routing (NSR)—This feature enablesa routerwith redundantRouting

Engines to switch fromaprimaryRoutingEngine toabackupRoutingEnginewithout

alerting peer nodes that a change has occurred.

• Routing Engine redundancy—This feature is enabled when two Routing Engines are

installed in the same router. One Routing Engine functions as the master, while the

other stands by as a backup to take over if the master Routing Engine fails.

• Graceful restart—A router undergoing a graceful restart relies on its neighbors (or

helpers) to restore its routing protocol information. The restart is themechanism by

which helpers are signaled to exit the wait interval and start providing routing

information to the restarting router.

[SeeUnderstandingHighAvailability Featureson JuniperNetworksRouters,Understanding

Graceful Routing Engine Switchover in the Junos OS, Nonstop Active Routing Concepts,

Understanding Routing Engine Redundancy on Juniper Networks Routers, and Graceful

Restart Concepts.]

• Support for MX Series Virtual Chassis onMX Series routers with MPC3E interfaces(MX Series routers with MPC3E interfaces)


This feature extends support for configuring a two-member MX Series Virtual Chassis

to MX240, MX480, and MX960 routers with MPC3Emodules (model number

MX-MPC3E-3D) installed. All MX Series Virtual Chassis features are supported.

In earlier JunosOS releases,MXSeries routers didnot supportMXSeriesVirtualChassis

configuration on MPC3Emodules.

[JunosOSHighAvailability ConfigurationGuide,MXSeries 3DUniversal EdgeRouter Line

Card Guide]



http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/high-availability-features-in-junos-introducing.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/gres-overview.html


http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/nsr-overview.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/routing-engine-redundacny-overview.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/graceful-restart-concepts.html


Interfaces and Chassis

• Support for high availability features (TXMatrix Plus routerwith 3DSIBs)—Startingwith Junos OS Release 13.1, the following high availability features are supported on

all routers in a routing matrix with a TXMatrix Plus router with 3D SIBs:

• Graceful Routing Engine switchover (GRES)—This feature enables a router with

redundant Routing Engines to continue forwarding packets, even if one Routing

Engine fails. GRES preserves interface and kernel information. In case of GRES with

NSR, the control plane is also preserved. During GRES, nearly 75 percent of line rate

worth of traffic per Packet Forwarding Engine remains uninterrupted during GRES.

• Nonstopactive routing (NSR)—This feature enablesa routerwith redundantRouting

Engines to switch fromaprimaryRoutingEngine toabackupRoutingEnginewithout

alerting peer nodes that a change has occurred.

• Routing Engine redundancy—This feature is enabled when two Routing Engines are

installed in the same router. One Routing Engine functions as the master, while the

other stands by as a backup to take over if the master Routing Engine fails.

• Graceful restart—A router undergoing a graceful restart relies on its neighbors (or

helpers) to restore its routing protocol information. The restart is themechanism by

which helpers are signaled to exit the wait interval and start providing routing

information to the restarting router.

[SeeUnderstandingHighAvailability Featureson JuniperNetworksRouters,Understanding

Graceful Routing Engine Switchover in the Junos OS, Nonstop Active Routing Concepts,

Understanding Routing Engine Redundancy on Juniper Networks Routers, and Graceful

Restart Concepts.]

• Extends support for Layer 2 policers toMX Series routers with MPC3


You can now configure Layer 2 policers for the ingress and egress interfaces on MX

Series routers with MPC3. Policer types include single-rate two-color, single-rate

three-color (color-blind and color-aware), and two-rate three-color (color-blind and

color-aware). To configure Layer 2 policing, include the policer statement at the [edit

firewall] hierarchy level.

• Support for active/active bridging and VRRP over IRB in MC-LAG for aggregatedEthernet (MX Series 3D Universal Edge Routers)




http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/high-availability-features-in-junos-introducing.html



http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/nsr-overview.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/routing-engine-redundacny-overview.html



Starting in Junos OS Release 13.1, MX240, MX480, and MX960 routers with MPC3

operating in multichassis link aggregation (MC-LAG) with aggregated Ethernet

configurations, support active/active bridging andVirtual Router RedundancyProtocol

(VRRP) over integrated routing and bridging (IRB).

The following multichassis Link Aggregation Control Protocol (LACP) group features

are currently supported:

• Active-Standbymode using LACP

• MC-LAG between two chassis

• Layer 2 circuit functions with ether-ccc encapsulation

• VPLS functions with ether-vpls and vlan-vpls encapsulation

• Network triangle and square topology

• Pseudowire status-tlv with independent mode

• LACP changes required to support MC-LAG

• Interchassis control protocol

Extended support for active/active bridging and VRRP over IRB, includes the following

features:

• Interchassis link (ICL-PL) for active/active bridging

• Active/active bridging

• VRRP over IRB for active/active bridging

• A single bridge domain cannot correspond to two RG-IDs

The following functionality is not supported:

• VPLS within the core

• Bridged core

• Name string being specified as service-id

NOTE: Some topologies are not supported and other restrictions apply tospecific network configurations. See the user documentation for details.

• Link Layer Discovery Protocol (LLDP) support (MX240, MX480, andMX960 3DUniversal Edge Routers)




You can configure the LLDP protocol on MX Series routers with MPC3. To configure

and adjust default parameters, include the lldp statement at the [edit protocols]

hierarchy level.

LLDP is disabled by default. At the [edit protocols lldp] hierarchy level, use the enablestatement to enable LLDPand the interfaces statement to enable LLDPon all or some

interfaces. Use the following statements at the [edit protocols lldp] hierarchy levelto configure or adjust the default LLDP parameters:

• advertisement-interval—Adjust the time interval (inseconds)atwhichLLDPadvertises

on the network. The default is 30 seconds.

• transmit-delay—Adjust the time (in seconds) by which LLDP delays successive

advertisements. The default is 2 seconds.

• hold-multiplier—Adjust the hold multiplier that LLDP uses to purge the cache or

learned information. The default is 4 (equivalent to 120 seconds with the default

advertisement interval).

• ptopo-configuration-trap-interval—Adjust the physical topology trap interval (in

seconds) at which LLDP sends SNMP traps containing statistics information. By

default this value is set to zero,which indicates that the topology changenotifications

are disabled. You can enable the change notifications by configuring a value from 1

through 3600 seconds.

• ptopo-configuration-maximum-hold-time—Adjust the physical topology maximum

hold time (in seconds) at which LLDP holds dynamic entries. The default is 300

seconds.

• lldp-configuration-notification-interval—Adjust the interval (in seconds) at which

SNMPtrapsare sent to themasterdatabase toupdatechanges in theLLDPdatabase

information. By default, this interval is set to zero indicating that the SNMP traps are

disabled. You can enable the configuration by setting a value from 1 through 3600

seconds.

• Enhancedmonitoring support for LACand LNS statistics onMXSeries 3DUniversalEdge Routers


Themonitoring commands displaying the L2TP access concentrator (LAC) and L2TP

network server (LNS) statistics have been enhanced to display new statistics

information that includes active and dead session data packets or octets for tunnels,

control and data packet counts across generic routing encapsulation (GRE) tunnels,

and L2TP summary statistics. You can view this information by including the statistics

keyword with the following monitoring commands:

• show services l2tp summary

• show services l2tp destination



• show services l2tp tunnel

• show services l2tp session

The output of the following commands has also been updated to display the new

statistics information:

• show services l2tp destination extensive

• show services l2tp tunnel extensive

• show services l2tp session extensive

• New command to clear LAC and LNS statistics onMX Series 3D Universal EdgeRouters


The clear services l2tp destination statistics command has been introduced to clear

L2TP access concentrator (LAC) and L2TP network server (LNS) statistics on MX

Series routers. The command clears the control and data packets (received or

transmitted) and the control error packet counts for all tunnels belonging to a

destination. You can use the following options with the new command:

• all–Clears all statistics for all tunnels belonging to a destination.

• local-gateway address–Clears statistics for tunnels belonging to the specified

local-gateway address.

• peer-gateway address–Clears statistics for tunnels belonging to the specified

peer-gateway address.

• L2TP support for AVPs 24 and 38 presented in the ICCNmessages on the LNS


Attribute-value pairs (AVPs) 24 and 38 are now supported in the

Incoming-Call-Connected (ICCN)messages that are sent by the L2TP access

concentrator (LAC) to the L2TP network server (LNS) in an L2TP session.

AVP 24 conveys the transmit speed of the subscriber’s access interface–that is, it

represents the speed of the connection from the LAC to the LNS, from the LAC

perspective (Tx). AVP 38 conveys the receive speed of the connection from the LNS

to the LAC, also from the LAC perspective (Rx). During the establishment of an L2TP

tunnel session, the LAC sends the L2TP (Tx) connect speed (in bits per second) AVP

24 to the LNS in ICCNmessages. The L2TP Rx connect speed (in bits per second) AVP

38 is included in the message when the Rx speed is different from the Tx speed. By



default, when the connection speed is the same in both directions, AVP 38 is not sent;

the LNS uses the value in AVP 24 for both transmit and receive speeds.

However, you can override this default behavior by configuring the

rx-connect-speed-when-equal statement at the [edit services l2tp]hierarchy level. This

configuration enables the sending of AVP 38 even when the connection speed is the

same in both directions.

You can also configure the Tx and Rx connect speed determination method using the

tx-connect-speed-method statement at the [edit services l2tp] hierarchy level. You can

choose from ancp, pppoe-ia-tag, or staticmethods to determine the connect speed.

The output of the showservices l2tp summary command has beenmodified to display

the Tx connect speed determination method and the state (enabled or disabled) of

theRx connect speedwhen the connection speed is equal in both directions. The show

services l2tp session extensive command output displays the actual Tx speed and Rx

speed for the session.

• Support for IP reassembly on an L2TP connection


You can configure the service interfaces on MX Series routers with MICs to support IP

packet reassembly on a Layer 2 Tunneling Protocol (L2TP) connection. The IP packet

is fragmented over an L2TP connection when the packet size exceeds the maximum

transmission unit (MTU) defined for the connection. Depending on the direction of the

traffic flow, the fragmentation can occur either at the L2TP access concentrator (LAC)

or at the L2TP network server (LNS), and reassembly occurs at the peer interface. (In

an L2TP connection, a LAC is a peer interface for the LNS and vice versa).

You can configure the service interfaces on the LAC or on the LNS to reassemble the

fragmented packets before they can be further processed on the network. On a router

running Junos OS, a service set is used to define the reassembly rules on the service

interface. The service set is then assigned to the L2TP service at the [edit services l2tp]

hierarchy level to configure IP reassembly for L2TP fragments.

You can view the reassembly statistics by using the show services inline ip-reassembly

stastics fpc fpc-slot | pfe pfe-slot> command.

[See IP Packet Fragment Reassembly for L2TP Overview.]

• New hardware configurations for the TXMatrix Plus router— In addition to the

TXP-T1600 configuration that supports up to four T1600 line-card chassis (LCC), the

following configurations are now supported for a routing matrix with a TXMatrix Plus

router:

• TXP-T1600-3D configuration supports up to eight T1600 LCCs.

• TXP-T4000-3D configuration supports up to four T4000 LCCs.



www.juniper.net/techpubs/en_US/junos13.2/topics/concept/l2tp-ip-reassembly-overview.html

• TXP-Mixed-LCC-3Dconfigurationsupports combinationsofT1600andT4000LCCs

such as:

• Six T1600 LCCs and one T4000 LCC

• Four T1600 LCCs and two T4000 LCCs

• Two T1600 LCCs and three T4000 LCCs

NOTE: For other valid combinations of T1600 and T4000 LCCs in theTXP-Mixed-LCC configuration, see the TXMatrix Plus Router Hardware

Documentation.

The following new hardware is supported:

• TXP-F13-3D SIBs (model number SIB-TXP-F13-3D) and TXP-F2-3D SIBs (model

number SIB-TXP-3D-F2S) in the TXMatrix Plus router switch-fabric chassis (SFC).

• TXP-LCC-3DSIBs (model number SIB-TXP-LCC-3D) and new rear fan trays (model

number FAN-R-TXP-3D-LCC) in the T1600 LCC or T4000 LCC.

• • CXP transceivers and CXP cables or active optical cable (AOC) transceiver for

connections between the TXP-F13-3D SIBs in the SFC and TXP-LCC-3D SIBs in the

LCC.

Each T1600 LCC adds up to 1.6 terabits per second (Tbps), full duplex (3.2 Tbps of

any-to-any, nonblocking, half-duplex) switching. Each T4000 LCC adds up to 2.0

terabits per second (Tbps), full duplex (4.0 Tbps of any-to-any, nonblocking,

half-duplex) switching.

To support the 3DSIBs, the SFC configuration size on the TXMatrix Plus craft interface

must be set to 3. You can view the status of front panel switch settings by using the

show chassis craft-interface operational mode command.

[See TXMatrix Plus Router Hardware Documentation.]

• Enhancement to show chassis environment sib command for TXMatrix Plus routerwith 3D SIBs—On TXMatrix Plus router with 3D SIBs, the output for the show chassis

environment sib command now displays the voltage parameter and the XF junction

temperature.

[See show chassis environment sib]

• Support for LCCmode configuration (TXMatrix Plus router with 3D SIBs)—Startingwith Junos OS Release 13.1, a routing matrix with a TXMatrix Plus router with 3D SIBs

supports the following configurations:

• TXP-T1600-3D configuration (supports up to eight T1600 LCCs): Supports LCC

numbers 0, 1, 2, 3, 4, 5, 6, and 7.

• TXP-T4000-3D configuration (supports up to four T4000 LCCs): Supports LCC

numbers 0, 2, 4, and 6.



http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/t-series/tx-matrix-plus/index.html



http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/command-summary/show-chassis-environment-sib.html

• TXP-Mixed-LCC-3Dconfigurationsupports combinationsofT1600andT4000LCCs

such as:

• Six T1600 LCCs and one T4000 LCC

• Four T1600 LCCs and two T4000 LCCs

• Two T1600 LCCs and three T4000 LCCs

NOTE: For other valid combinations of T1600 and T4000 LCCs in theTXP-Mixed-LCC configuration, see the TXMatrix Plus Hardware Guide.

To enable these configurations, youmust configure the LCCmode on the TXMatrix

Plus router with 3D SIBs. To configure the LCCmode, include the set lcc-mode lcc

lcc-numbermode (empty | t1600 | t4000) statement at the [edit chassis] hierarchy

level. By default, the LCCmode is set to t1600.

To view the configured LCCmode information, use the show chassis lcc-mode

operational mode command.

NOTE:• The LCCmode t4000 is supported only on the even-numbered LCCs

LCC 0, LCC 2, LCC 4, and LCC 6.

• When you set the LCCmode as t4000, youmust set the next LCC

(odd-numbered)mode as empty. For example, if you set LCCmode

t4000 on LCC2, then youmust set the LCC3mode as empty. Otherwise,

the commit operation fails. Setting the LCCmode for an LCC as empty

disables the control plane and data plane connections between thatLCC and the SFC, so the LCC does not come online.

[SeeRoutingMatrixwithTXP-T1600-3DConfiguration,RoutingMatrixwithTXP-T4000-3D

Configuration, Routing Matrix with TXP-Mixed-LCC-3D Configuration, lcc-mode.]

• Inline flowmonitoring support for VPLS traffic onMX Series routers


Starting with Release 13.1, Junos OS extends the inline flowmonitoring support on MX

Series routers to VPLS traffic. Junos OS releases earlier than 13.1 support only IPv4

(family inet) and IPv6 (family inet6) traffic for inline flowmonitoring.

Inline flowmonitoringsupport enablesyou toconfigureactive sampling tobeperformed

on an inline data path without the need for a services Dense Port Concentrator (DPC).

To enable inline flowmonitoring for VPLS traffic, include the following statements at

the [edit sampling instance instance-name] hierarchy level:




http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/routing-matrix-txp-t1600-3d-overview-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/tx-matrix-plus-txp-t4000-3d-overview-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/tx-matrix-plus-txp-t4000-3d-overview-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/tx-matrix-plus-txp-mixed-lcc-3d-overview-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/configuration-statement/edit-chassis-lcc-mode.html

family vpls {output {flow-server flow-server {port port-number;version-ipfix {template {vpls_template ;}

}inline-jflow {source-address source-ip;

}}

}}

Youmight also want to specify the size of the VPLS flow table by including the

vpls-flow-table-size size statement at the [edit chassis fpc slot inline-services

flow-table-size] hierarchy level. The supported range is 1 through 15; however, the sum

of the IPv4, IPv6, and VPLS flow table size must not exceed 15. Also, note that any

update to the flow-table-size configuration triggers a reboot of the FPC because the

flow table sizes are set during the FPC initialization stage.

Only inline flowmonitoring is supported for VPLS traffic. You cannot configure family

vpls for PIC-basedmonitoring.

The following limitations of inline flowmonitoring apply to the inline flowmonitoring

of the VPLS traffic as well:

• Sampling run-length and clip-size are not supported.

• For inline configurations, each family can support only onecollector, and thecollector

can be either IPv4 or IPv6.

When you have configured family vpls, the show services accounting errors inline-jflow

fpc-slot slot and show services accounting flow inline-jflow fpc-slot slot commands

also provide information related to the VPLS family.

[Services Interface]

• Enhancements to services interface and service set configurations—To improveresource optimization and network efficiency, Junos OS introduces the following

enhancements to services interfaces and service set configurations in Release 13.1 and

later.

• close-timeout—The close-timeout statement at the [edit interfaces interface-name

services-options]hierarchy level enables you toconfigurea timeoutperiod for ending

any TCP connection thatwas not properly closed.When close-timeout is configured,

a timer is initiated on receipt of a packet with the FIN flag set, and if the two-way

handshake is not completed in the specified close-timeout interval, Junos OS closes

the connection. The default value for close-out is 20 seconds.

• cpu-load-threshold—The cpu-load-threshold statement at the [edit interfaces

interface-name service-options session-limit] hierarchy level enables you to regulate

the usage of CPU resources. The cpu-load-threshold can be set as a percentage of



the total available CPU resources. If the CPU usage exceeds the configured

cpu-load-threshold, the system reduces the rate of new sessions so that the existing

sessions are not affected by low CPU availability. The CPU utilization is constantly

monitored, and if the CPU usage remains in overload state-that is, above the

cpu-load-threshold value configured-for a continuous period of 5 seconds, Junos

OS reduces the session rate value configured at [edit interfaces interface-name

services-options session-limit rate] by 10 percent. This is repeated until the CPU

utilization comes down to the configured limit.

You can use the show services service-sets summary, show services service-sets

statistics packet-drops, and show services service-setsmemory-usage commands

to monitor and verify this configuration.

• header-integrity-check—The enable-all statement at the [edit services service-set

service-set-nameservice-set-optionsheader-integrity-checks]hierarchy level enables

you to configure Junos OS to verify the packet header for anomalies in IP, TCP, UDP,

and IGMP information and to flag such anomalies and errors.

You can use the show services service-sets statistics integrity-drops command to

monitor and verify this configuration.

[Services Interfaces]

• Support forOSSmappingto representaT4000chassisasaT1600oraT640chassis(T4000routers)—Startingwith JunosOSRelease 13.1R2, youcanmapaT4000chassisto a T1600 chassis or a T640 chassis, so that the T4000 chassis is represented as a

T1600chassisor aT640chassis, respectively,without changing theoperations support

systems (OSS) qualification. Therefore, you can avoid changes to the OSSwhen a

T1600 chassis or a T640 chassis is upgraded to a T4000 chassis. You can configure

the OSSmapping feature with the set oss-mapmodel-name t640|t1600 configuration

command at the [edit chassis] hierarchy level. This command changes the chassis

field to the known chassis field in the output of the show chassis hardware and the

show chassis oss-map operational mode commands. You can verify the change with

the show snmpmibwalk system and show snmpmibwalk jnxBoxAnatomy operational

commands as well. You can delete the OSSmapping feature with the delete chassis

oss-mapmodel-name t640|t1600 configuration command.

• Extends support for multilink-based protocols on T4000 and TXMatrix Plusrouters—Startingwith JunosOSRelease 13.1R2,multilink-basedprotocolsaresupportedon the T4000 and TXMatrix Plus routers with Multiservices PICs.

• Multilink Point-to-Point Protocol (MLPPP)—Supports Priority-based Flow Control

(PFC) for data packets and Link Control Protocol (LCP) for control packets.

Compressed Real-Time Transport Protocol (CRTP) and Multiclass MLPPP are

supported for both data and control packets.

• Multilink Frame Relay (MLFR) end-to-end (FRF.15)—Supports Ethernet Local

Management Interface (LMI), Consortium LMI (C-LMI), and Link Integrity Protocol

(LIP) for data and control packets.

• MultilinkFrameRelay(MFR)UNINNI (FRF.16)—SupportsEthernetLocalManagement

Interface (LMI), Consortium LMI (C-LMI), and Link Integrity Protocol (LIP) for data

and control packets.



• Link fragmentation and interleaving (LFI) nonmultilink MLPPP and MLFR packets.

• Communications Assistance for Law Enforcement Act (CALEA)--Defines electronic

surveillance guidelines for telecommunications companies.

• Two-Way Active Measurement Protocol (TWAMP)-- Adds two-way or round-trip

measurement capabilities

[Interfaces Command Reference]

• Extends support of IPv6 statistics forMLPPPbundlesonT4000andTXMatrixPlusrouters—Starting with Junos OS Release 13.1R2, the show interfaces lsq-fpc/pic/port

command displays the packet and byte counters for IPv6 data for Multilink

Point-to-Point Protocol (MLPPP) bundles on link services intelligent queuing (LSQ)

interfaces.

[Interfaces Command Reference]

• Traffic blackhole causedby fabric degradation support (TXMatrix router)—Startingin Junos OS Release 13.1R3, the support for limiting the traffic black-hole time by

detecting Packet Forwarding Engine destinations that are unreachable over the fabric

is extended to the TXMatrix router.

Junos OS XML API and Scripting

• SLAXdebugger available through the JunosOSCLI—Starting with Junos OS Release13.1, the Junos OS command-line interface (CLI) includes the SLAX debugger (sdb),

which is used to trace the execution of scripts that are enabled in the configuration.

To invoke the SLAX debugger from the CLI on a device running Junos OS, issue the opinvoke-debuggerclioperationalmodecommand, include thescriptname,andoptionallyinclude any necessary script arguments.

user@host> op invoke-debugger cli script <argument-name argument-value>

[See SLAX Debugger, Profiler, and callflow.]

Subscriber AccessManagement

• RADIUS accounting data backup and restoration (MX Series routers)


You can configure the router to preserve RADIUS accounting data when the RADIUS

accounting server or the network connecting to the server experiences an outage. The

router can also replay that data to the server when communication is restored, so that

billing data is not lost. If you do not configure accounting backup, RADIUS accounting

data is lost for the duration of the outage after the router has exhausted its attempts

to resume contact with the RADIUS server.



http://www.juniper.net/techpubs/en_US/junos13.1/topics/topic-map/junos-script-automation-libslax-slaxproc-debugger-profiler-callflow.html

By default, the router must wait until the revert timer expires before it can attempt to

contact the non-responsive server again. However, when you configure accounting

backup, the revert timer is disabled and the router immediately retries its accounting

requestsassoonas the router fails to receiveaccountingacknowledgments.Accounting

backup follows this sequence:

1. The router fails to receive accounting acknowledgments from the server.

2. The router immediately attempts to contact the accounting server andmarks the

server asoffline if the router doesnot receiveanacknowledgmentbeforeexhausting

the number of retries.

3. The routernextattempts tocontact in turnanyadditional accountingserverspresent

in the RADIUS profile.

If a server is reached, then the router resumes sending accounting requests to this

server.

4. If none of the servers responds or if there are no other servers in the profile, the

router declares a timeout and begins backing up the accounting data. It withholds

all accounting stopmessages and does not forward new accounting requests to

the servers.

5. During the outage, the router sends a single pending accounting stopmessage to

the servers at periodic intervals.

6. If one of the servers acknowledges receipt, then the router sends all the pending

stopmessages to that server in batches at the same interval until all the stored

stopmessages have been sent. However, any new accounting requests are sent

immediately rather being held and sent periodically.

You can include themax-pending-accounting-stops statement at the [edit access]

hierarchy level to set themaximumnumber of pendingaccounting stopmessages that

the router backs upwhen the accounting servers are offline. You can specify a number

in the range 1 through 168,000; the default value is 168,000 stopmessages. After the

maximum number of messages has been withheld, subsequent subscriber logins fail.

Include themax-withhold-time statement at the [edit access]hierarchy level to specify

how long the pending accounting stopmessages can be held, in the range 1 through

1440minutes; the default value is 60minutes. When this time passes, all accounting

stopmessages still in the pending queue are flushed, even if the accounting server has

come back online.

Several newcommandssupport this feature. Youcan force the router tobegin replaying

all pending stopmessages without first waiting for the expiration of the interval by

issuing the request network-access aaa replay pending-accounting-stops command.

When you do so, the router first replays a batch of stopmessages to the server; if it

receives an acknowledgment of receipt, then the router sends all remaining pending

stopmessages in order.

The show network-access aaa statistics pending-accounting-stops command displays

the total number of pending stopmessages. You can issue the show accounting

pending-accounting-stops command to display all statistics for the all pending

accounting stopmessages on the router, including both service and session requests.



You can include the name of an access profile to display statistics for only that profile,

or you can include the terse keyword to display minimal statistics.

[Subscriber Access]

• Subscriber interfaces over MPLS pseudowires (MX Series routers)


Subscriber management supports the creation of subscriber interfaces over

point-to-point MPLS pseudowires. The pseudowire is a tunnel that is either an

MPLS-basedLayer 2VPNor Layer 2 circuit. Thepseudowire tunnel transports Ethernet

encapsulated traffic from an access node (for example, a DSLAM) to the MX Series

router that hosts the subscriber management services. The MX Series router end of

the pseudowire tunnel is similar to a physical Ethernet, and is the point at which

subscriber management is performed.

Subscriber management’s pseudowire subscriber interface support enables you to

take advantage of MPLS capabilities such as failover and rerouting, and to utilize a

single pseudowire to service a large number of DHCP and PPPoE subscribers.

To configure pseudowire subscriber interface support, you:

1. Set the number of pseudowire devices supported by the router

2. Configure the pseudowire subscriber logical interface device

3. Configure the transport logical interface

4. Configure the pseudowire logical device

5. Configure the service logical interface

6. Configure the underlying interface device

7. Configure the signaling protocol

8. (Optional) Associate a dynamic profile to the pseudowire logical interface

9. (Optional) Configure CoS parameters and BA classification

10. (Optional) Configure interface sets

11. (Optional) Configure PPPoE over the pseudowire logical device

NOTE: Subscriber interfacesoverMPLSpseudowiresare supportedonMXSeries routers with MPCs.

The following new statements are introduced to support subscriber interfaces over

pseudowires.



Table 2: New Statements for Pseudowire Subscriber Interfaces

DescriptionHierarchyStatement

Specify the logical tunnel (lt) interface that processes thepseudowire termination, in the format lt-x/y/z.

[edit interfaces ps device-number]anchor-point

Configure the number of pseudowire logical devices availableto the router.

[edit chassis pseudowire-service]device-count

Configure the pseudowire logical interface device.

NOTE: The pseudowire interface configuration supports asubset of the physical Ethernet configuration options.

[edit logical-system transport-lsinterfaces]

ps device-number

Configure properties for pseudowire devices.[edit chassis]pseudowire-service

Specify that the router supports untagged traffic onpseudowire subscriber interfaces.

[edit interfaces ps device-number]untagged

[Subscriber Access]

• Enable store subscriber access interface descriptions and report the interfacedescription through RADIUS


Youcanconfigure JunosOS to store subscriber access interfacedescriptionsand report

the interface description through RADIUS. This capability enables you to uniquely

identify subscribersonaparticular logical orphysical interface.Whenyouenable storing

of the interface descriptions, RADIUS requests include the interface description in VSA

26-63, if the subscriber’s access interface has been configured with an interface

description. All interface descriptionsmust be statically configured using the JunosOS

CLI. Storing and reporting of interface descriptions is supported for DHCP, PPP, and

authenticated dynamic VLANS, and applies to any client session that either

authenticates or uses the RADIUS accounting service. The description can contain

letters, numbers, and hyphens (-), and can be up to 64 characters long.

You can enable or disable storage and reporting of interface descriptions as follows:

• To enable storing and reporting of interface descriptions, include the

report-interface-descriptions statement at the [edit access] hierarchy level.

• Todisable storingand reportingof interfacedescriptions, include the radiusattributes

exclude statement at the [edit access profile profile-name] hierarchy level.

• Enhancements to ANCP support (MX Series routers)




ANCP support has been enhanced as follows:

• In addition to the previously supported static VLAN andVLANdemux interfaces and

interface sets, ANCP now supports dynamic VLAN and VLAN demux interfaces and

interface sets, dynamic VLAN-tagged interface sets, dynamic agent circuit identifier

(ACI) ACI interface sets, and dynamic DHCP IP demux and PPPoE subscriber

interfaces.

• RADIUS authentication and accounting is supported for DHCP IP demux andPPPoE

subscribers. During authentication, the configuredmapping between an access line

and the interface or interface set takes precedence over a dynamic mapping

generated during the authentication process. An access line can be statically

remapped to a different interface or interface set and the traffic shaping is adjusted

as appropriate for the newmapping.

• CoS traffic shaping is preserved for new and existing subscriber sessions when the

TCP connection with an access node is terminated by non-administrative means.

• Access lines are nowdynamicallymapped to aDHCP IPDemuxor PPPoE subscriber

interface when the ACI is present in the PPPOE or DHCP discovery packet and the

subscriber interface isnotamemberofan interfaceset. In earlier releases, theaccess

line is mapped to the subscriber’s underlying VLAN or VLAN demux interface.

• When an ACI interface set is dynamically created for DHCP IP demux or PPPoE

sessions thatall share the sameACI, ANCPdynamicallymaps theACI to the interface

set. The ACI must be present in the DHCP or PPPoE discovery packets.

• When a VLAN-tagged interface set is dynamically created for DHCP IP demux or

PPPoE sessions that share the sameVLAN tag, you can configure ANCP to statically

map the ACI to the interface set (this is possible because the set has a deterministic

name).

• ANCP supports CoS-related adjustments to the upstream and downstream data

rate it receives fromtheaccessnode fordynamically createdVLANsanddynamically

created ACI interface sets.

To configure recommended (advisory) upstream and downstream data rates on

dynamically created VLAN interfaces, include the upstream-rate rate or

downstream-rate rate statementsat the [editdynamic-profilesprofile-name interfaces

$junos-interface-ifd-nameunit$junos-interface-unitadvisory-options]hierarchy level.

To configure the recommended data rates on dynamically created ACI interface

sets, include the upstream-rate rate or downstream-rate rate statements at the [edit

dynamic-profiles profile-name interface-set $junos-interface-set-name interfaces

$junos-interface-ifd-name advisory-options] hierarchy level.

• Several new commands are available in this release. The show ancp summary

command displays counts and states for all ANCP neighbors and subscribers. You



can issue the show ancp summary neighbor command to display only neighbor

information, or display information for a particular neighbor and its associated

subscribers by specifying the neighbor’s IP address or MAC address. Finally, you can

display information just for ANCP subscribers by issuing the show ancp summary

subscriber command.

[Subscriber Access]

• IPv4 addresses saved for dual-stack PPP subscribers (MX Series router withMPCs/MICs)


This feature enables you to save IPv4 addresses for dual-stack PPP subscribers when

you are not using the IPv4 service. This feature provides on-demand IP address

allocation or de-allocation after the initial PPP authentication and IPv6 address or

prefix allocation. For dynamic profiles, changing this setting takes effect for any new

subscribers. This feature also enables you to include Unisphere-IPv4-release-control

VSA in the Access-Request that is sent during on-demand IP address allocation. You

can also include Interim-Accounting messages that are sent to report an address

change.

To enable on-demand IP address allocation, include the on-demand-ip-address

statement at the following hierarchy levels:

• [edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit”

ppp-options]

• [edit interfaces pp0 unit “$junos-interface-unit” ppp-options]

• [edit protocols ppp-services]

• [edit access profile profile-name radius options]

To enable the Unisphere-IPv4-release-control VSA in RADIUSmessages, include

ip-address-change-notify notify-name in the [edit access profile profile-name radius

options] hierarchy.

To enable an immediate interim accounting message when the IP address changes,

include address-change-immediate-update in the [edit access profile profile-name

accounting] hierarchy.

To enable an immediate interim accounting message when the IP address changes,

include address-change-immediate-update in the [edit access profile profile-name

accounting] hierarchy.

[Subscriber Access Configuration Guide]

• Support for 802.3ad LAG stateful port and DPC redundancy for PPPoE overaggregated Ethernet (MX Series router with MPCs/MICs)




This feature provides support for 802.3ad link aggregation group (LAG) stateful port

and dense port concentrator (DPC) redundancy. This feature supports targeted

distribution of non-replicated (stacked) PPPoE or IP-Demux links over VLAN-Demux

links, which in turn are over an aggregated Ethernet (AE) logical interface. Service

providers with PPPoE or IP-Demux interfaces for CoS configurations can now:

• Provide DPC and port redundancy to subscribers

• Apply hierarchical QoS (H-QoS) per subscriber and firewall filters on subscriber

traffic over 802.3ad LAG

To enable targeted distribution, include the targeted-distribution statement at the

[edit-interfaces pp0 unit] hierarchy level.

[Subscriber Access Configuration Guide]

• AAA accountingmessages during RADIUS server changes in access profiles (MXSeries routers)


The Junos OS authd process sends accounting messages when an access profile’sRADIUS server status changes. When the first RADIUS server is added to an access

profile, the authd process sends an Acct-Onmessage. When the last RADIUS server

is deleted from an access profile, authd sends an Acct-Off message.

Toenable this accounting feature, youconfigure the send-acct-status-on-config-change

statement at the [edit access profile profile-name accounting] hierarchy level.

[Subscriber Access]

• Configure subscriber interfaces over pseudowire terminations—MPLS accesspseudowiresallowyou toconfigure subscriber interfacesoverpseudowire terminations.

The pseudowire termination acts as a virtual Ethernet. Subscriber interfaces native to

the physical Ethernet interfaces can be configured over the Ethernet-like interface,

thereby creating subscriber services over pseudowire terminations. A pseudowire

interface resides on a logical tunnel, which uses either L2 circuit signaling or L2VPN

signaling. Junos OS supports Ethernet pseudowires for MPLS access by defining

pseudowire services (ps) physical interfaces, which represent the pseudowire and the

attachment circuits as described in RFC 3985, PseudoWire Emulation Edge-to-Edge

(PWE3) Architecture. In an edge network, the pseudowire can represent a single

subscriber or multiple subscribers.

Junos OS supports two aspects of CoS for MPLS access pseudowires. The first aspect

is support for applying rewrite rules and BA classifiers to MPLS access pseudowires.



The second aspect of CoS is the ability to perform egress hierarchical shaping towards

thesubscriber. CoSsupports twoand three level hierarchical schedulingconfigurations

for egress shaping on MPLS access pseudowires.

• Access profile support for RADIUS Calling-Station-ID attribute (MX Series routerswith MPCs/MICs)


This feature enables you to configure an access profile on the router to provide an

alternative value for the Calling-Station-ID (RADIUS IETF attribute 31). The

Calling-Station-ID attribute enables the network access server (NAS) to use the

Access-Request message to send the phone number fromwhich the request (call)

originated.

To configure an alternative value for the Calling-Station-ID attribute, use the new

calling-station-id-format statement at the [edit access profile profile-name radius

options] hierarchy level. You can include one or more statement options to enable the

Calling-Station-ID to transmit any combination of the following values to the RADIUS

server:

• Agent circuit identifier (agent-circuit-id)—String that uniquely identifies the

subscriber’s access node and the digital subscriber line (DSL) on the access node.

ForDHCP traffic, the agent circuit identifier (ACI) string is in theDHCPoption82 field

of DHCPmessages. For PPPoE traffic, the ACI string is in the DSL Forum

Agent-Circuit-ID VSA [26-1] of PPPoE Active Discovery Initiation (PADI) and PPPoE

Active Discovery Request (PADR) control packets.

• Agent remote identifier (agent-remote-id)—String that identifies the subscriber on

the digital subscriber line access multiplexer (DSLAM) interface that initiated the

service request. The agent remote identifier (ARI) string is stored in either the DHCP

option 82 field for DHCP traffic, or in the DSL Forum Agent-Remote-ID VSA [26-2]

for PPPoE traffic.

• Interface description (interface-description)—Description of the interface, which is

not included in Calling-Station-ID by default.

• NAS identifier (nas-identifier)—Name of the NAS that originated the authentication

or accounting request. NAS-Identifier is RADIUS IETF attribute 32.

For example, the following statement configures an access profile named retailer01

to include the ACI string, NAS identifier, and interface description in the

Calling-Station-ID attribute:

[edit access profile retailer01 radius options]user@host# set calling-station-id-format agent-circuit-id nas-identifierinterface-description

If you configure the calling-station-id-format statement with more than one optional

value, as shown in the preceding example, a hash character (#) is the default delimiter



that the router uses as a separator between the concatenated values in the resulting

Calling-Station-ID string. To configure an alternative delimiter character for the

Calling-Station-ID string, use the new calling-station-id-delimiter statement at the

[edit access profile profile-name radius options] hierarchy level. Youmust enclose the

delimiter character in quotation marks.

For example, the following statement configures an asterisk (*) as the delimiter

character in access profile retailer01:

[edit access profile retailer01 radius options]user@host# set calling-station-id-delimiter “*”

[Subscriber Access]

• Support for applyingRADIUSattributes forCoS traffic shaping todynamic interfacesets during authentication ofmember subscriber sessions (MX Series routers withMPCs/MICs)


To control bandwidth at a household level in a subscriber access network, you can

apply RADIUS class of service (CoS) traffic shaping attributes to a dynamic interface

setand itsmember subscriber sessionswhen thesubscriber sessionsareauthenticated.

In earlier Junos OS releases, you used RADIUS to apply CoS scheduling attributes to

authenticated dynamic subscriber sessions, but not to the dynamic interface set

representing the household fromwhich the subscriber sessions originated.

In the context of this feature, ahousehold is thedynamic interface set or dynamicagent

circuit identifier (ACI) interface set of which the subscribers sessions are members. A

subscriber session, also referred toasa client sessionor subscriber interface, is adynamic

VLAN, PPPoE, or DHCP subscriber interface that belongs to the dynamic interface set.

Applying RADIUS attributes for CoS traffic shaping to a dynamic interface set and its

member subscriber sessions is supported for the following network configurations:

• Dynamic IP demultiplexing (IP demux) subscriber interface over either a dynamic

interface set or a dynamic ACI interface set

• DynamicPPPoEsubscriber interfaceovereitheradynamic interfacesetoradynamic

ACI interface set

Using this feature involves the following basic steps:

1. In the traffic-control profiles that you configure for the dynamic subscriber session

and thedynamic “parent”ACI interface set, reference JunosOSpredefineddynamic

variables corresponding to RADIUS attributes with a tag value in the 100s range.

The set of existing $junos-cos-parameter predefined variables for traffic-control

profiles has been duplicated and assigned a tag value in the 100s range. The tag

value is the only difference between the existing predefined variables and the new

predefined variables. For example, the existing $junos-cos-shaping-rate predefined



variable is assigned RADIUS vendor ID 4874, attribute number 108, and tag value

2 (T2). To configure this feature, youmust use the new $junos-cos-shaping-rate

predefined variable that is assigned RADIUS vendor ID 4874, attribute number 108,

and tag value 102 (T102).

For a complete list of the Junos OS predefined variables and RADIUS attribute

values that you can use with this feature, see the Junos OS Subscriber Access

Configuration Guide.

2. In the dynamic profile for the subscriber interface, configure traffic control profiles

for the subscriber session and for the “parent” ACI interface set at the [edit

dynamic-profiles profile-name class-of-service traffic-control-profiles] hierarchy

level.

The following simpleexample shows the class-of-service stanza inadynamicprofile

namedpppoe-subscriber for a dynamicPPPoE subscriber interface over a dynamic

ACI interface set. The traffic-control-profiles stanza defines two traffic-control

profiles: tcp-pppoe-session for the dynamic PPPoE subscriber session, and

tcp-parent-aci-set for the dynamic “parent” ACI interface set. The

$junos-cos-shaping-ratepredefinedvariable included ineachof these traffic-control

profiles is assigned RADIUS vendor ID 4874, attribute number 108, and tag value

102 (T102). The interfaces stanza applies output traffic-control profile

tcp-pppoe-session to the dynamic PPPoE (pp0) subscriber interface, and

output-traffic-control-profile tcp-parent-aci-set to the dynamic ACI interface set.

[edit]dynamic-profiles {pppoe-subscriber {class-of-service {traffic-control-profiles {tcp-pppoe-session {scheduler-map smap-1;shaping-rate "$junos-cos-shaping-rate";overhead-accounting frame-mode;

}tcp-parent-aci-set {shaping-rate "$junos-cos-shaping-rate";overhead-accounting frame-mode;

}}interfaces {pp0 {unit "$junos-interface-unit" {output-traffic-control-profile tcp-pppoe-session;

}}interface-set "$junos-interface-set-name" {output-traffic-control-profile tcp-parent-aci-set;

}}

}}

}



As part of this feature, several new $junos-cos-shaping-rate-parameter predefined

variables have been added to control traffic shaping rates on a per-priority basis for

dynamic subscriber sessions and their “parent” ACI interface set. These predefined

variables for per-priority traffic shaping are assigned RADIUS vendor ID 4874, attribute

number 108, and tag values in the range 116 through 126.

[Subscriber Access]

• Support for Ethernet OAM on S-VLANswith associated C-VLANs and subscriberinterfaces (MX Series routers with MPCs/MICs)


When Ethernet IEEE 802.1ag Operation, Administration, and Maintenance (OAM)

connectivity fault management (CFM) is configured on a static single-tagged service

VLAN (S-VLAN) logical interface on a Gigabit Ethernet, 10-Gigabit Ethernet, or

aggregated Ethernet physical interface, you can now configure the router to propagate

the OAM state of the S-VLAN to the associated dynamic or static double-tagged

customer VLAN (C-VLAN) logical interfaces.

If theCFMcontinuity checkprotocoldetects that theOAMstateof theS-VLAN isdown,

you can configure the underlying physical interface to bring down all associated

C-VLANs on the interface with the same S-VLAN (outer) tag as the S-VLAN interface.

In addition, the router brings down all DHCP, IP demultiplexing (IP demux), andPPPoE

logical subscriber interfaces configured on top of the C-VLAN. Propagation of the

S-VLAN OAM state to associated C-VLANs ensures that when the OAM state of the

S-VLAN link is down, the associated C-VLANs and all subscriber interfaces on top of

the C-VLANs go down as well.

In earlier Junos OS releases when Ethernet OAMwas configured on an untagged,

single-tagged, or dual-tagged logical interface, the CFM continuity check affected the

OAM status of only that interface. Because no relationship existed between

single-tagged S-VLAN and double-tagged C-VLAN logical interfaces with the same

S-VLAN (outer) tag, the router did not bring down the associated C-VLANs and the

logical subscriber interfaces configured on the C-VLANs when the continuity check

detected that the S-VLAN link was down. With this new configuration option for

S-VLANsonGigabitEthernet, 10-GigabitEthernet, andaggregatedEthernet interfaces,

the CFM continuity check affects the OAM status not only of the S-VLAN link, but also

ofallassociatedC-VLANs,DHCPsubscribers,DHCPwith IPdemuxsubscriber interfaces,

and PPPoE subscriber interfaces configured on the C-VLANs.

To enable propagation of the S-VLAN OAM state to associated C-VLAN logical

interfaces, use the new oam-on-svlan option when you configure a Gigabit Ethernet

(ge), 10-Gigabit Ethernet (xe), or aggregated Ethernet (ae) interface. For example, the

following statement configures Gigabit Ethernet physical interface ge-1/0/3 to

propagate the OAM state of the S-VLAN to the associated C-VLANs:

[edit]user@host# set interfaces ge-1/0/3 oam-on-svlan



To illustrate how this feature works, consider the following sample configuration on

Gigabit Ethernet interface ge-1/0/3:

• Single-tagged S-VLAN interface ge-1/0/3.0, which has a single S-VLAN outer tag,

VLAN ID 600

• Double-tagged C-VLAN interface ge-1/0/3.100, which has an S-VLAN outer tag,

VLAN ID 600, and a C-VLAN inner tag, VLAN ID 1

• PPPoE logical subscriber interfaces configured on C-VLAN interface ge-1/0/3.100

• Ethernet OAM CFM protocol configured on the static S-VLAN interface, but not on

the C-VLAN interface

Because the S-VLAN and C-VLAN interfaces in this example have the same S-VLAN

outer tag (VLAN ID 600), the router brings down the C-VLAN interface and the PPPoE

logical subscriber interfaces when the CFM continuity check detects that the OAM

status of S-VLAN interface ge-1/0/3.0 is down.

EthernetOAMsupport forS-VLANsandassociatedC-VLANs isnot currently supported

for use with dynamic profiles, S-VLAN trunk interfaces, or C-VLAN trunk interfaces.

[Subscriber Access]

• Support for shared IPv4 and IPv6 service sessions on PPP access networks


This feature simplifies your configuration by allowing you to configure one dynamic

service profile that supports IPv4, IPv6, or both IPv4 and IPv6. It allows subscribers to

share the same service session using IPv4 and IPv6 address families. If you define IPv4

and IPv6 in the dynamic service profile, one address family or both address families

can be activated for the service. When the service is activated, matched packets are

tagged with the same traffic class and treated the same way for both IPv4 and IPv6

traffic.

• Deactivating Services

If both IPv4 and IPv6 service sessions are active, and a deactivation message is

received for one of the address families (IPv4 or IPv6), all active services for that

address family are deactivated. If one address family remains active on the service,

the service session remains in the ACTIVE state. If the address family that is

deactivated is the only family currently running on the service session, the service

returns to the INIT state.

• Accounting

Only one Accounting-Start message is sent for each service session regardless of

the number of address families that are active. Statistics for each address family of

a service session are cumulative across service activations and deactivations of the

service.



• Show commands

The show subscribers extensive and shownetwork-access aaa subscribers session-id

commands have changed to show the family (IPv4, IPv6) that is active for the

subscriber session.

System Logging

• New and deprecated system log tags—The following system logmessages are no

longer documented, either because they indicate internal software errors that are not

caused by configuration problems or because they are no longer generated. If these

messages appear in your log, contact your technical support representative for

assistance:

• ANCPD_COMMAND_OPTIONS

• SFW_LOG_FUNCTION

• MCSN_ABORT

• MCSN_ACTIVE_TERMINATE

• MCSN_ASSERT

• MCSN_ASSERT_SOFT

• MCSN_EXIT

• MCSN_SCHED_CALLBACK_LONGRUNTIME

• MCSN_SCHED_CUMULATVE_LNGRUNTIME

• MCSN_SIGNAL_TERMINATE

• MCSN_START

• MCSN_SYSTEM

• MCSN_TASK_BEGIN

• MCSN_TASK_CHILDKILLED

• MCSN_TASK_CHILDSTOPPED

• MCSN_TASK_FORK

• MCSN_TASK_GETWD

• MCSN_TASK_MASTERSHIP

• MCSN_TASK_NOREINIT

• MCSN_TASK_REINIT



• MCSN_TASK_SIGNALIGNORE

• WEB_CERT_FILE_NOT_FOUND_RETRY

User Interface and Configuration

• Command for displaying optical port information (TXMatrix Plus routers with 3DSIBs)—Starting with Junos OS Release 13.1, the show chassis fabric optics command

displays information about the optical ports on the SIB-TXP-3D-F13 SIB on the

switch-fabric chassis and theSIB-TXP-3D-LCCSIBon the line-cardchassis ina routing

matrix. You can use the sfc or lcc options of this command to view information about

specific optical ports.

[See show chassis fabric optics.]

• Support for unified in-service software upgrade (TXMatrix Plus router)—Startingwith Junos OS Release 13.1R2, unified in-service software upgrade (unified ISSU) is

supported on a routing matrix based on a TXMatrix Plus router with the TXP-T1600

configuration.

Unified ISSU is a process to upgrade the system software with minimal disruption of

transit traffic and no disruption on the control plane. In this process, the new system

software versionmustbe later than theprevious systemsoftware version.Whenunified

ISSU completes, the new system software state is identical to that of the system

software when the system upgrade is performed by powering off the system and then

powering it back on.



http://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-chassis-fabric-optics.html

VPLS

• PIM Snooping for VPLS


PIM snooping is done to restrict multicast traffic to interested devices in a VPLS. This

feature was introduced in an earlier release and is now fully supported on MX Series

devices.

A new statement, pim-snooping, is introduced at the [edit routing-instances

instance-name protocols] hierarchy level to configure PIM snooping on the PE device.

PIM snooping configures a device to examine and operate only on PIM hello and

join/prune packets.

A PIM snooping device snoops PIM hello and join/prune packets on each interface to

find interestedmulticast receivers and populates the multicast forwarding tree with

this information. PIM snooping can also be configured on PE routers connected as

pseudowires, which ensures that no new PIM packets are generated in the VPLS, with

the exception of PIMmessages sent through LDP on the pseudowire.

PIM snooping improves IP multicast bandwidth in the VPLS core. Only devices that

are members of a multicast group receive the multicast traffic meant for the group.

This ensuresnetwork integrity and reliability, andmulticastdata transmission is secured.

[See Example: Configuring PIM Snooping for VPLS.]

RelatedDocumentation

Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release


•

• Known Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

on page 37

• Resolved Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

on page 73





Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release 13.1 forM Series, MX Series, and T Series Routers

• Changes in Default Behavior and Syntax on page 32

• Changes Planned for Future Releases on page 36


Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

http://www.juniper.net/techpubs/en_US/junos13.1/topics/topic-map/pim-snooping-vpls.html

Changes in Default Behavior and Syntax

The following are changes made to Junos OS default behavior and syntax.

• Interfaces and Chassis on page 32

• IPv6 on page 34

• Junos XML API and Scripting on page 34

• Multicast on page 35

• Multiprotocol Label Switching (MPLS) on page 35

• Network Management on page 35

• Routing Protocols on page 35

• System Logging on page 36


• The Switch Control Board (SCB) framer in MX Series routers supports only the

first-generation synchronization status message (SSM) format. Therefore, whenever

the router needs to transmit an SSM value of ST3E or TNC via an external interface,

an SSM value of ST3 is transmitted.

However, on a Synchronous Ethernet interface, an ESMC packet with the unadjusted

SSM is transmitted. The term unadjusted here means:

• If the receive-quality statement at the [edit chassis synchronization selection-mode]

hierarchy level is configured, the originally received SSM value ST3E or TNC

(corresponding to the currently active Synchronous Ethernet clock interface) is

transmitted.

• If theconfiguredqualitystatementat the [editchassissynchronizationselection-mode]

hierarchy level is configured, the originally configured SSM value of ST3E or TNC

(corresponding to the currently active Synchronous Ethernet clock interface) is

transmitted.

Note that when the external interface receives an SSM value of either ST3E or TNC,

the SCB framer does not recognize either of these SSM codes, and therefore, it reports

that the Do Not Use (DNU) quality value has been received.

• OnMX80 routers, the FPC Slot output field has been changed to TFEB Slot for the

show services accounting flow inline-jflow, show services accounting errors inline-jflow,

and show services accounting status inline-jflow commands.

• Starting with Junos OS Release 13.1R1, a new option -I has been added to the nhinfo

command (that is, nhinfo –I), which displays the next-hop index space allocation on

the MX Series 3D Universal Edge Routers. The following sample output displays the

next-hop index space allocation for the nhinfo –I command:

NH Index Space Allocation=======================================================Index_Space_type Used AvailableReserved 50 1344 Private 30 704



Regular 49 260094Extended 0 2097149

• ProtectionofMX,M, andTseries routers fromdenial of service (DOS)attacks—NewCLI options provide improved protection against DOS attacks.

• NATmapping refresh behavior—Prior to this release, a conversation was kept alive

wheneither inboundoroutbound flowswereactive.This remains thedefaultbehavior.

As of 13.1R2 release, you can also specify mapping refresh for only inbound flows or

only outbound flows. To configure mapping refresh behavior, include the

mapping-refresh (inbound | outbound | inbound-outbound) statement at the [edit

services nat rule rule-name term term-name then translated secure-nat-mapping]

hierarchy level.

• EIF inbound flow limit—Previously. the number of inbound connections on an EIF

mapping was limited only by the maximum flows allowed on the system. You can

now configure the number of inbound flows allowed for an EIF. To limit the number

of inboundconnectionsonanEIFmapping, include theeif-flow-limitnumber-of-flows

statement at the [edit services nat rule rule-name term term-name then translated

secure-nat-mapping] hierarchy level.

• Changes to DDoS protocol groups (MX Series routers)—The ipv4-unclassified andipv6-unclassified DDoS protocol groups have been deprecated in the protocols

statementat the [edit systemddos-protectionddos]hierarchy level. These twoprotocol

groupshavealsobeendeprecated fromthe showddos-protectionprotocolscommands.

These groups formerly were used to police all unclassified IPv4 and IPv6 host-bound

traffic.

In their place, 10 new protocol groups have been added to the protocols statement

and the show ddos-protection protocols commands:

• control-layer2—Unclassified Layer 2 control packets.

• control-v4—Unclassified IPv4 control packets.

• control-v6—Unclassified IPv6 control packets.

• filter-v4—Unclassified IPv4 filter action packets; sent to the host because of reject

terms in firewall filters.

• filter-v6—Unclassified IPv6 filter action packets; sent to the host because of reject

terms in firewall filters.

• host-route-v4—Unclassified IPv4 routing protocol and host packets in traffic sent to

the router local interface address for broadcast andmulticast.

• host-route-v6—Unclassified IPv6 routing protocol and host packets in traffic sent

to the router local interface address for broadcast andmulticast.

• other—All unclassified packets that do not belong to another type.

• resolve-v4—Unclassified IPv4 resolve packets sent to the host because of a traffic

request resolve action.

• resolve-v6—Unclassified IPv6 resolve packets sent to the host because of a traffic

request resolve action.



[DDoS Configuration]

• SNMPTrapsforSPMBcrashevents(TSeries)—The jnxFruTableobject (in theChassisMIB) is supported for SPMB (Switch Processor Mezzanine Board) crash events on T

Series routers. You can use the show log chassisd command to view the SNMPMIB

objects.

• SNMP Traps for FPC crash events (T Series)—The jnxFruTable object (in the ChassisMIB) is supported for FPC crash events on T Series routers. You can use the show log

messages | match trap command to view the SNMP Traps.

• The LIST DTCP now displays the option Flags as BOTH in addition to the existing

options.

IPv6

• Change in automatically generated virtual-link-local-address for VRRP over IPv6—The seventh byte in the automatically generated virtual-link-local-address for VRRP

over IPv6 is 0x02. This changemakes the VRRP over IPv6 feature in Junos OS 12.2R5,

12.3R3, 13.1R3, and later releases inoperablewith JunosOS 12.2R1, 12.2R2, 12.2R3, 12.2R4,

12.3R1, 12.3R2, and 13.1R1 releases if an automatically generated

virtual-link-local-address ID used. As a workaround, use amanually configured

virtual-link-local-address instead of an automatically generated

virtual-link-local-address.

Junos XML API and Scripting

• Junos XML protocol support for <get-configuration> requests for logical systemusers—Startingwith JunosOSRelease 13.1, the JunosXML<get-configuration>operationsupports the <configuration> root tag for logical system configurations.Within a Junos

XML protocol session, a logical systemuser can use the <get-configuration> operation

to request specific logical system configuration hierarchies using child configuration

tags as well as request the entire logical system configuration. When requesting the

entire logical system configuration, the RPC reply now includes the <configuration>

root tag. Prior to Junos OS Release 13.1, the <configuration> root tag was omitted.

[Junos XML Management Protocol Guide]

• IPv6 address text representation is stored internally and displayed in commandoutput using lowercase—Starting from Junos OS Release 11.1R1, IPv6 addresses are

stored internally and displayed in the command output using lowercase. Scripts that

match on an uppercase text representation of IPv6 addresses should be adjusted to

either match on lowercase or perform case-insensitve matches.

• <get-configuration> RPCwith inherit="inherit" attribute returns correct timeattributes for committed configuration—Prior to Junos OS Release 13.1R1, when youconfigured some interfaces using the interface-range configuration statement, if you

later requested the committed configuration using the <get-configuration> RPCwith

the inherit="inherit" and database="committed" attributes, the device returned

junos:changed-localtime and junos:changed-seconds in the RPC reply instead of

junos:commit-localtime and junos:commit-seconds. This issue is fixed in Junos OS

Release 13.1R1 and later releases so that the device returns the expected attributes in

the RPC reply.



Multicast

• PIMSnoopingforVPLS—PIMsnooping isdone to restrictmulticast traffic to interested

devices in a VPLS. This feature was introduced in an earlier release and is now fully

supported on MX Series routers.

A new statement, pim-snooping, is introduced at the [edit routing-instances

instance-name protocols] hierarchy level to configure PIM snooping on the PE device.

PIM snooping configures a device to examine and operate only on PIM hello and

join/prune packets.

A PIM snooping device snoops PIM hello and join/prune packets on each interface to

find interestedmulticast receivers and populates the multicast forwarding tree with

this information. PIM snooping can also be configured on PE routers connected as

pseudowires, which ensures that no new PIM packets are generated in the VPLS, with

the exception of PIMmessages sent through LDP on the pseudowire.

PIM snooping improves IP multicast bandwidth in the VPLS core. Only devices that

are members of a multicast group receive the multicast traffic meant for the group.

This ensuresnetwork integrity and reliability, andmulticastdata transmission is secured.

[See Example: Configuring PIM Snooping for VPLS.]

Multiprotocol Label Switching (MPLS)

• Theminimum-bandwidth-adjust-threshold-valuestatementat the [editprotocolsmpls

label-switched-path] hierarchy level is deprecated in the Junos OS CLI in Release 13.1

and later. If the user configures minimum-bandwidth, the value will be assigned

automatically.

• Themaximum value that can be assigned for theminimum-bandwidth-adjust-interval

statement at the [editprotocolsmpls label-switched-path]hierarchy level is 31536000

seconds. Theminimum value that can be assigned for this statement is 300 seconds.

Network Management

• EachRoutingEngine runs itsownSNMPprocess (snmpd), allowingeachRoutingEngine

to maintain its own engine boots. However, if both Routing Engines have the same

engine ID and the Routing Engine with a lesser snmpEngineBoots value is selected as

themaster Routing Engine during the switchover process, the snmpEngineBoots value

of the master Routing Engine is synchronized with the snmpEngineBoots value of the

other Routing Engine.

[Network Management Configuration Guide]

Routing Protocols

• JunosOSRelease 13.1 introducesanewCLI configurationcommandunder the [protocols

amt relay] hierarchy:

set <routing-instances foo> protocols amt relay tunnel-devices [ ud-ifd1 ud-ifd2 ... ]

This is similar to [protocols pim tunnel-devices]. Includes syntax, up to 32 ud-ifd's, and

(unlike pim) are not hidden in any instance. Only accepts physical interfaces beginning

with "ud-".



http://www.juniper.net/techpubs/en_US/junos13.1/topics/topic-map/pim-snooping-vpls.html

• Starting in Junos OS Release 14.1, Junos OSwill modify the default BGP extended

community value used for MVPN IPv4 VRF route import (RT-import) to the

IANA-standardizedvalue. Thus, thedefault behaviorwill change such that thebehavior

of themvpn-iana-rt-importstatementwill becomethedefault. Themvpn-iana-rt-import

statement will be deprecated and should be removed from configurations.

System Logging

• Prior to Junos OS Release 11.4, routers used APIs to display commit time warnings.

Starting with Junos OS Release 12.2, API warnings are replaced with system log

messages (with ERRMSG).

[System Log]

Changes Planned for Future Releases

The following are changes planned for future releases.

Routing Protocols

• Change in the Junos OS Support for the BGPMonitoring Protocol (BMP)—In JunosOS Release 13.3 and later, the currently supported version of BMP, BMP version 1, as

defined in Internet draft draft-ietf-grow-bmp-01, is planned to be replaced with BMP

version3, asdefined in Internetdraftdraft-ietf-grow-bmp-07.txt. JunosOScansupport

only one of these versions of BMP in a release. Therefore, Junos OS release 13.2 and

earlier will continue to support BMP version 1, as defined in Internet draft

draft-ietf-grow-bmp-01. JunosOS release 13.3and later support only theupdatedBMP

version 3 defined in Internet draft draft-ietf-grow-bmp-07.txt. This also means that

beginning in JunosOS 13.3, BMPversion3configurationsarenotbackwardscompatible

with BMP version 1 configurations from earlier Junos OS releases.

[Routing Protocols]



on page 3

•


on page 37


on page 73







Known Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

Thecurrent software release isRelease 13.1. For informationaboutobtaining the software

packages, see “Upgrade and Downgrade Instructions for Junos OS Release 13.1 for M

Series, MX Series, and T Series Routers” on page 121.

• Class of Service (CoS)

• Forwarding and Sampling

• General Routing

• High Availability (HA) and Resiliency

• Infrastructure

• Interfaces and Chassis

• Layer 2 Features

• Layer 2 Ethernet Services

• Multiprotocol Label Switching (MPLS)

• NetworkManagement andMonitoring

• Platform and Infrastructure

• Routing Policy and Firewall Filters

• Routing Protocols

• Services Applications

• Software Installation and Upgrade

• Subscriber AccessManagement

• User Interface and Configuration

• VPNs

Class of Service (CoS)

• This cosmetic issue is specific of 3D line cards, based on MX Series router with MPCs

or MICs. In these cards, the logical interfaces with family mpls do not have any EXP

rewrite rule applied by default. In other words, EXP value is copied from the previous

codepoints: for example, from IP Precedence in IPv4->MPLS next hops. However, the

command "show class-of-service interface" still shows the exp-default rule as if it

wasapplied(in fact, it isn't): user@router>showclass-of-service interfacege-2/3/1.204

| match rewrite Rewrite exp-default exp (mpls-any) 33 PR824791

• COSD errors COSD_GENCFG_WRITE_FAILED: GENCFGwrite failed (op, minor_type)

= (add, ifl tcp) for tbl 14828 if 255 lsq-3/2/0.13 Reason: File exists 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 /2/0Reason: File exists are during Routing Engine

switchover PR827538

• Traffic-control-profile-remaining is not working for ifl in interface-set PR835933



http://prsearch.juniper.net/PR824791




• Whenever a VLAN ID is changed for an interface that has ieee802.1 classifier applied,

we see the error COSD_GENCFG_WRITE_FAILED errror messages. The only impact of

this is the syslog message. There is no impact on functionality. PR838379

• Commit throwsanerror "Invalid rewrite rule rule-namefor ifl<ifl-name>. Ifd<ifd-name>

is not capable to rewrite inner vlan tag 802.1p bits" even though there is no rewrite

configuration related to inner-vlan tag. PR849710

• The output of the “show subscribers extensive” command displays the Effective

shaping-rate field only if you have enabled the effective shaping rate at the [edit

chassis] hierarchy level. PR936253

• After swappingMPC2E-3D-QcardwithMPC2E-3D-EQcard, an interface is still running

out of queues with only 32k queues in use. PR940099

Forwarding and Sampling

• In normal conditions, after adding member interface to Aggregate Ethernet (AE) or

Aggregate Sonet (AS) interface on MX-FPC, reference count of the AE/AS interface

gets incremented.And the referencecount getsdecrementedwithdeletionofmember

interface from aggregate interface. But in some rare conditions, reference count has

not been incremented for addition but reference count is tried to be decremented

which would result in l2ald process crash and core file. PR809873

• Without the fix, for family inet6, “traffic-class” is a termination action, this is incorrect.

With the fix, this behavior no longer a termination action; we can add another

termination action eg. Next-term to the filter. PR852016

• When committing a firewall filter with a "then decapsulate" action, the router may

throw the following errors Feb 19 11:20:59 user@host dfwd[45123]:

DFWD_FW_PGM_READ_ERR: Read of segment 0/0 in filter 2 failed: Unknown error: 0

Feb 19 11:21:01 user@hostdfwd[45123]:DFWD_CONFIG_WRITE_FAILED: Failed towrite

firewall filter configuration for FILTER idx=2 owned by CLI. Error: Message too long This

issuehappensonanMXthathasatleastone i-chipboard (MXwithDPC).Thishappens

because the Firewall Daemon fails to properly update the Packet Forwarding Engine

firewall configuration. PR857708

• With Enhanced CFEB or MS-DPC (which are I-Chip based) used, when sampling and

interface-style NAT are configured, then upon reboot router or I-Chip based Flexible

PIC Concentrator (FPC), the packets should be sampledmight occasionally be sent

to the egress interface for forwarding, resulting in duplicate packets being sent out.

PR861984

• This is a cosmetic issue. If we prepare following conditions, we can find this behavior

when we delete interface policer configuration. We cannot see this behavior without

"commit synchronize". < Conditions > 1. Use 64bit Junos OS. 2. Configure

"graceful-restart" and "policer". 3. Delete interface policer configuration and then hit

"commit synchronize".<backupREmessages>Apr 11 14:04:08.030 router-re1 /kernel:

dfw_update_local_shared_policer: new filter program should be NULL for op 3 If you

find this issue with fixed code, please re-configure "system syslog". PR873084

• Accounting-data log file name uses configured system time. PR880175













• VPLS connections in MI state—In rare scenarios, the routing protocol daemon can fail

to read themesh-group information from kernel, which might result in the VPLS

connections for that routing-instance to stay inMI (Mesh-Group IDnotavailable) state.

The workaround is to deactivate/activate the routing-instance. PR892593

• After committing some configuration changes (e.g. deactivate an interface), while the

Packet Forwarding Engine daemon (pfed) tries to get statistics of some nodes, it may

encounter a NULL node, causing pfed to crash and generate a core file. PR897857

• Whenwe configure unsupported firewall filter on channelized interfaces, commit error

message showwithout this fix wasmisleading. With this fix, commit error will have a

message like below: mgd: error: layer2-policer is not supported for interface so-3/2/0

PR897975

• OnMX Series routers with MPCs or MICs with the "fast-filter-optimization" knob

enabled, at least two prefixes are configured with "except" keyword, and an explicit

default route is also configured.When the traffic that does notmatch any of the prefix

with except keyword, the IPv4 firewall filtermaynotbeevaluatedcorrectly, and leading

traffic to hit the default reject rule. For example: family inet { filter example { term 1 {

from { source-address { 0.0.0.0/0; 172.16.0.0/12 except; 10.0.0.0/8 except; } } then

accept; }With theaboveconfiguration,anypacketwithsource IPother than 172.16.0.0/12

and 10.0.0.0/8 shouldmatch term1. However, thismatchdid notwork correctly leading

such traffic to hit the default reject rule. PR899676

• We can find this issue, if we set firewall counter of IPv6's payload-protocol. Even if we

confirm this counter using "show snmpmib walk jnxFWCounter ascii", we cannot see

this counter. It's cosmetic issue. So this firewall works fine. Router# run show snmp

mib walk jnxFWCounter ascii

jnxFWCounter."__default_arp_policer__"."__default_arp_policer__" =

__default_arp_policer__ <<<<<<<<<<We cannot find counter. PR899800

• Filter state failed to be present in the kernel andwas not created onPacket Forwarding

Engine. Added check to retry creating filter state before pushing to Packet Forwarding

Engine. PR937607

General Routing

• Theknob route-memory-enhanced(hierarchy: set chassis) is hidden inplatformsM320

and MX Series. There is no functionality break but this knob shouldn't be hidden.

PR690100

• For an IPv4 pool, only the all-0 host and the all-1 host addresses are precluded from

allocation, both for gateway-assigned and external address assignment. PR729144

• MPLS LDP/RSVP traceroute does not work if you have a default route 0/0 pointing to

discard on the egress router with DPC cards. PR790935

• BFD packets sent from FPC (distributedmode) over normal physical interfaces are

set with ttl 0 so that it gets decremented by 1 and becomes 255 once it is sent out on

thewire. This behavior is not the casewhen theBFDpackets are sent over IPsec routed

tunnels where the packets are sent from the corresponding service PIC. In this case,

the ttl should be set to 255 as no such decrement action takes place when it is sent












from a service PIC. But in the current scenario, the ttl is set to 0 as a result of which the

servicepicdrops theoutgoingpacket. Thiswasanuntestedscenario till date.PR808545

• ICMP redirects are not disabled even after configuring no-redirects on irb interface.

PR819722

• When we execute the CLI command "show app-engine virtual-machine instance

detail", if thevirtual-machine (VM) isnotACTIVE, there shouldbeamessagedisplayed

if it is waiting for secondary disk space to be available or for a particular interface to

come up. In the fix we add themessage. PR824665

• Changing static route with qualified-next-hop and order option to next-hop option

results in static route missing from route table. We need to restart routing process to

see the route again. PR830634

• Insubscribermanagementenvironment,withdynamic-profileconfiguredforsubscribers,

with high churn rate of subscribers, memory leak is observed in authd process. This

was observed from a login/logout or flapping of 1000 subscribers every 3 minutes.

PR835204

• =>Enabling bidirectional PIM feature (possibly pim rpwith 224.0.0.0/4 group) and rpd

restart. This issue is hit during regression test for PIM bidir. 2) HW type of

chassis/linecard/RE. If it affectsall, just say?all?.=>all. 3)Suspectedsoftware feature

combination. (If customer turns on feature X along with Y, they may hit, etc)

=>bidirectional PIM feature (rp configured) and rpd restart is causing the issue. 4)

Describe if any behavior/ change to existing function =>None. PR836629

• When the transit traceroute packets with ttl=1 are received on the LSI interface, you

may retrieve the Source Address from the LSI interface to reply ICMP. As LSI does not

have any IFA, it will use first the IFA in routing-instance to reply. So Source Address

usedwas the first IFA added in VPN routing-instance. As aworkaround, if the incoming

interface is LSI, then retrieve Source Address from the logical interface which is having

the Destination IP Address. This will make sure we reply with Source Address from

CE-facing the logical interface. PR839920

• WhenMX Series router running with DPC is upgraded by ISSU, some of interface may

show incorrect input packet/byte count. And the incorrect count is also seen to the

related interface MIB. The value will be a large number. Physical interface: xe-3/1/0,

Enabled, Physical link is Up Interface index: 138, SNMP ifIndex: 5449, Generation: 141

Link-level type: Ethernet, MTU: 1514, LAN-PHYmode, Speed: 10Gbps, BPDU Error:

None, Loopback: Local, Source filtering: Disabled, Flow control: Enabled Device flags

: Present Running Loop-Detected Interface flags: SNMP-Traps Internal: 0x4000 Link

flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0

ms, Down 0ms Current address: 00:24:dc:9c:7c:30, Hardware address:

00:24:dc:9c:7c:30 Last flapped : 2013-01-13 14:36:25 JST (02:07:52 ago) Statistics

last cleared: Never Traffic statistics: Input bytes : 3867797326912475 0 bps Output

bytes : 0 0 bps Input packets: 15108583308733 0 pps Output packets: 0 0 pps ~snip~

Logical interface xe-3/1/0.0 (Index 196614) (SNMP ifIndex 5450) (Generation 140)

Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2 Traffic statistics: Input bytes

:3867797326912475Outputbytes :0 Inputpackets: 15108583308733Outputpackets:

0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0

Transit statistics: Input bytes : 3867797326912475 0 bps Output bytes : 0 0 bps Input










packets: 15108583308733 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500,

Generation: 160, Route table: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags:

Is-Preferred Is-Primary Destination: 10.3.1/24, Local: 10.3.1.1, Broadcast: 10.3.1.255,

Generation: 141 Protocol multiservice, MTU: Unlimited, Generation: 161, Route table: 0

Policer: Input: __default_arp_policer__ gladiolus:Desktop$ grep .5449

mib_value_after_issu.txt ifName.5449 = xe-3/1/0 ifInMulticastPkts.5449 = 0

ifInBroadcastPkts.5449 = 0 ifOutMulticastPkts.5449 = 0 ifOutBroadcastPkts.5449 =

0 ifHCInOctets.5449 = 3867797326912475 ifHCInUcastPkts.5449 = 0

ifHCInMulticastPkts.5449 = 0 ifHCInBroadcastPkts.5449 = 0 ifHCOutOctets.5449 =

0 ifHCOutUcastPkts.5449 = 0 ifHCOutMulticastPkts.5449 = 0

ifHCOutBroadcastPkts.5449=0gladiolus:Desktop$grep .5450mib_value_after_issu.txt

ifName.5450 = xe-3/1/0.0 ifInMulticastPkts.5450 = 0 ifInBroadcastPkts.5450 = 0

ifOutMulticastPkts.5450 = 0 ifOutBroadcastPkts.5450 = 0 ifHCInOctets.5450 =

3867797326912475 ifHCInUcastPkts.5450 = 15108583308733

ifHCInMulticastPkts.5450 = 0 ifHCInBroadcastPkts.5450 = 0 ifHCOutOctets.5450 =

0 ifHCOutUcastPkts.5450 = 0 ifHCOutMulticastPkts.5450 = 0

ifHCOutBroadcastPkts.5450 = 0 PR847106

• The core is hit during the load balancing scenarios and AMS scenario. Issue is not seen

all the time. PR851167

• Ptsp failed to append policy with multi-rules since 'msg over size limit' PR852224

• Default tunnel-mtupacketsof size9137Bytesandabovedonotpassover IPsec tunnels.

PR855081

• When the router runs at full scale for a very long period of time, during which it

experiences network failures, all SDB logical unit numbers appear to be used up. The

lack of unit numbers causes login failures for subsequent additional subscribers.

PR855181

• MPLS-IPv4 performance is 10% less than the expected 2.5 mpps. PR855865

• If mtu value is set onms-x/y/z of MS-MIC/MS-MPC and packets abovemtu size are

sent, then these packets will be dropped. PR856140

• When an MPC fails in a specific manner, while failing it continues to send traffic into

the switching fabric for a time, the fabric ASICs report errors such as these with large

counts: chassisd[82936]: %DAEMON-3: New CRC errors found on xfchip 0 plane 0

subport 16xfport4new_count 17651aggr_count 17651 chassisd[82936]:%DAEMON-3:

New CRC errors found on xfchip 0 plane 0 subport 17 xfport 4 new_count 17249

aggr_count 17249 chassisd[82936]: %DAEMON-3: New CRC errors found on xfchip 0

plane0subport 18xfport4new_count65535aggr_count65535This cancauseDPC(s)

to stall and not send traffic into the switching fabric to other DPCs or MPCs. Messages

suchas thesemaybe reportedby theaffectedDPC(s) : [Err] ICHIP(1)_REG_ERR:packet

checksum error in output fab_stream 4 pfe_id 64 [Err] ICHIP(1)_REG_ERR:packet

checksum error in output fab_stream 6 pfe_id 64 [Err] ICHIP(1)_REG_ERR:packet

checksum error in output fab_stream 8 pfe_id 64 This failure on the affected DPCs

persists, and will likely affect all traffic destined to the fabric from affected DPCs. The

only temporary resolution is to restart the affected DPCs, which will resume fabric

traffic from the affected DPCs. PR856560











• 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

• ATMMIC back-to-back, too many IFLs(more than 8k) may cause certain IFLs to go

down. PR859165

• In a virtual chassis with scaled environment, the standby chassis tends to reset slots

during the transition period after power down themaster chassis. PR859717

• When the fxp0 interface on a k2re is administratively disabled, the local end shows

the link as down while the far end device displays the status as up. PR862952

• MS-MPC interfaces fail to come up, If the MX Series routers are configured for IRB

configuration PR862999

• Whena switchover to the backupmember interface is done in anAMS interface having

N:1 fail-over config, the session distribution on themember interfaces might not be

proper after the backup becomes new active interface. This may result in traffic loss

due to over subscription of sessions on one of the member interface of AMS bundle.

PR863834

• Fixing thebehaviorofANCP 'pre-ietf-mode'whenAN isset todraft-00mode.PR864782

• ANCP Sender Name is not the source MAC address. PR868130

• During a reference clock switch T4 will be switched off. PR868161

• The 1588v2 BMCA procedure causes a frequency hold-over event in the system under

test. PR868422

• Configuration of Container Interfaces for APS on MX Series FPCs is not allowed since

Junos OS 12.1. If this feature is needed on MX Series legacy FPCs, use a release with

this PR fixed. PR869192

• PPPoE IPv6access routermightnot respond to the first ICMPv6RSmessage.PR869212

• RPD crashes after changing the configuration of router-advertisement. When the

configuration begins with the following, then perform the actions specified below: ##

## inactive:protocols router-advertisement## interfacege-0/0/1.1 { virtual-router-only;

} 1. Activate the router-advertisementwith theActivateprotocols router-advertisement

command. 2. Deactivate the router-advertisement with the Deactivate protocols

router-advertisement interface ge-0/0/1.1 command. 3. Set the configuration using

theSetprotocols router-advertisement interfacege-0/0/1.2 command.After you issue

commit check, there are no problems. However, after you issue commit, RPD fails and

a core file with the following logs is generated: rpd[1422]:

RPD_RA_CFG_UNKNOWN_ACTION: Unknown configuration action 3 received. This

issue occurs for any type of interface. PR871359

• When an ANCP neighbor transitions to a down state, the information for that neighbor

is no longer displayed by the show ancp subscriber command. PR871897

















• Under high scale, expiry of a Kernel side reconnect timer would cause it to send a

non-servicablemsg to thepfe(asking the linecards to restartand resyncsince reconnect

failed) Since there is no ack- to this Kernel msg, Kernel thought it sent the msg and

untoggles the GRES flag. The pfewasn't expecting anything so it continued along. The

EFFECT: The system is permanently not ready for GRES... CLI GRES check will always

report: [cmd] request chassis routing-enginemaster switchcheckApr 14 19:03:13 [INFO

] warning: Standby Routing Engine is not ready for graceful switchover. PR873679

• Because the default setting for the relay groupmerging is disabled, this results in a

support limit of 16 linecards within the VC. Even with the groupmerge disabled, line

cards may have been grouped at system start-up. That means no issue when system

start-up with more than 16 line cards, but restart any of the line cards might result in

the Packet Forwarding Engine on it to crash and never recover. PR874791

• OnMX-VC platform, when themaster Routing Engine declares GRES ready by CLI

command, there is a time window before some FPCs to be actually ready. After

performing GRES, these GRES unready FPCsmight get rebooted, resulting in traffic

loss. PR877248

• PPPoE subscriber service session fails when agent circuit ID and agent remote ID

information is too long. PR877364

• SNMP trap is not generated upon Fabric chip failure/offline/online state on MX Series

routers with MPCs or MICs. PR877653

• MX Series routers terminate session in case 'No Framed-IPv6-Prefix from Radius'.

PR877948

• PPPoE subscriber connection fails as a result of cosd parse failure at dynamic profile.

PR882713

• On an MX Series router, the lldpd process on a redundant server Node groupmight

crash after a commit operation if there are multiple unknown type, length, and value

(TLV) elements included in the LLDP PDUs. PR882778

• authd reports syntaxerror, although the syntax is correct,when trying toactivate service

profile for subscriber and fails to activate the service PR883065

• We cannot change "flow term-order" behavior without "restart routing". Although

"restart routing" restores this behavior, all routes are affected. PR885091

• Rpdmight crash when deactivate rib-groups (inet and inet6) under protocols IS-IS,

also these rib-groups applied under interface-routes. The core files could be seen by

executing CLI command "show system core-dumps". PR885679

• In MX virtual chassis (MXVC) scenario, nexthop statistic requests such as "showmpls

lsp statistics" from the Kernel to the Packet Forwarding Engines have to go via relay

daemon. Under scaled configurations, the nexthop statistic requests message that is

being sent to theBm-RoutingEngine is bigger than themaxallowedsize, causing kernel

on Mm-Routing Engine to crash with core files generated, then Mm-Routing Engine

goes down. PR886864

• The backup Routhing Engine failed to commit with error "pdb_update_ddl_id: cannot

get new id for "dynamic-profiles dynamic-profiles profile-name", commit full is a

workaround. PR888454
















• Observed a traffic-drd daemonmight hang once after logging into service PIC and

restarting the net-monitor daemon. PR889982

• Whenmultiple framed-route(type-22) AVPs are present in Radius access accept

message, the router will install only the first route into the routing table. PR891036

• FollowingaglobalGRESevent, thenewMaster(VC-Mm)will expect relayd to reconnect

to it in less than 40 seconds. However under high scale, such as with 54k

dual-stack(v4v6) or 110k+ single-stack DHCP subscribers, owing either to a slow

relayd(relay daemon) control connection to the Kernel, or due to slow pfe reconnects

to relayd,wearenotable tomeet the40seconds timer requirementcausingsubsequent

FPC reboots and traffic loss. PR891814

• ICMP TTL Expired sent by PFE has inaccurate rate limit for ES-FPC. PR893598

• InMX-VC environment, the FPCsmight get rebooted during VC-MmperformingGRES.

PR896015

• OnM40e/M160 platforms, after offlining of any FPC (not fpc-slot 5), interfaces on

FPC slot 5 will be deleted. PR898415

• In subscriber management environment, in a rare case, VLAN auto-sensing daemon

(autoconfd) might crash and generate a core file due to Session Database (SDB) is

inaccessible. PR899747

• Some ATM interfaces may stay down after flapping the Circuit Emulation MIC.

PR900926

• The flat accounting files are made compliant to the documentation described XML

schema. PR902019

• MX-VC: VC port convesion not working for second set of added VC ports for VCB.

PR906922

• In high scale DHCP/PPPoE subscriber management environment (120k subscribers),

when the VC-Mm (master Routing Engine of the virtual-chassis) powers down, even

though the new VC-Mm (former VC-Bm) can take over the mastership, but the

subscribersmight beofflineandcannot recover because the kernel of thenewVC-Mm

is too busy to service internal connection request. PR908027

• After FPC/MPC is reset or while PPPoA customer login, in rare case, the ppp daemon

(jpppd) might get an incorrect value from device control daemon (dcd) which might

cause all the new Link Control Protocol (LCP) messages to be ignored and results in

static PPPoA sessions can not come up. This problem is seen on MX Series products

so far, but the problem is mostly common and if other products are using the same

version of Junos OS software, it might apply to them. PR912496

• After changing interface description, it doesn't get updated in "show lldp neighbors"

output. PR913792

• 10GbE interface onMIC3-3D-10XGE-SFPP stays up even if far end is disabled andgoes

down. Since the interface on MIC3-3D-10XGE-SFPP cannot react to remote failure,

CCC circuit cannot change the state correctly, if port of MIC3-3D-10XGE-SFPP is

configured as CCC end point. PR914126

















• The following note applies for 16x 10GEMPC:With respect to this feature, when ISSU

is performed from feature non-supporting version (ex. 12.2, 13.1) to feature supporting

version (12.3R5, 13.2R3, or 13.3), then 16x 10GE FPC needs reboot in order to use this

feature. PR914772

• ancpdmemory leak, when bouncing 1000 business subscribers. PR915431

• In multi-router Automatic Protection Switching (APS) scenario, the laser of the

protection link might be turned off and never come back on when the ATM (at-)

interface of the Circuit EmulationMIC flap or theMIC restarts. In such conditions, if the

working link goes down, APS fails to switch traffic to the protection link. PR917117

• Alogmessage"%DAEMON-3:CannotperformnhoperationADDANDGETnhop0.0.0.0

type unicast nhindex 0x0 ifindex 0xd3e <interface name> fwd nhidx 0x0 type unicast

errno 45 suppressed <number of suppressed> logs" is generated if access-internal

route is created during the dynamic interface configuration process. The log message

can be permanent or not. Besides this message there were no side effects. PR917459

• An FPC crash can be triggered by an SBE event after accessing a protectedmemory

region, as indicated in the following log: "System Exception: Illegal data access to

protectedmemory!" 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 locationby readingand flushingout the32-byte cache line containing

that location in an attempt to update that memory location with correct data. If that

memory location is read-only, it causesan illegalaccess toprotectedmemoryexception,

as 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 the CPU

has a good copy of the data to continue its execution path. PR/919681 canbe triggered

on both PTX and T4000 platforms and can be seen in Junos OS releases 12.1 and 12.3.

Fix is available in 12.3R5, 12.3R3-S6, 13.3R1, 13.2R2. Crash signature in the FPC shell

shows the following: SNGFPC4(router-re0 vty)# sh nvram System NVRAM : 32751

available bytes, 2477 used, 30274 free Contents: [LOG] Set the IP IRI for table #1 to

0x80000014 [LOG] IPV4 Init: Set the IP IRI to 0x80000014 [LOG] GN2405: JSPEC

V 1.0 Module Init. <..> Reset reason (0x84): Software initiated reset, LEVEL2

WATCHDOG [Sep 6 17:16:07.231 LOG:Warning] <164>DDR: detected 3 SDRAM

single-bit errors [Sep 6 17:16:07.231 LOG:Warning] <164>DDR: last error at addr

0x108d2378, bad data/mask0x00240401fffffff7/0x0000000000000008 bad

ecc/mask=0xbe/0x00 System Exception: Illegal data access to protectedmemory!

<<< Event occurred at: Sep 6 17:16:07.231087 PR919681

• MX80 routers now support CLI command "show system resource-monitor summary".

PR925794

• Following chassisd messages might be observed after executing the "show chassis

fabric summary" command, FM: Plane Sate: 1 1 1 1 2 2 0 0; staggered_pmask: 15 2a 00

00 00 00 00 00 FM: Mux active/trained: 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0; Mode:1

act_mask:3f These are non-impacting debugmessages. Junos OS Release 12.3R5 and

later has the fix. PR927453

• MS-PICmight crash in IPsec environment after deleting "tcp-mss" knob under IPsec

"service-sets" hierarchy. PR930741











• When P2MP LSP is protected by link protection, it could have active andmultiple

standby next-hop. If one of the next-hops, regardless of whether it is an active or

standbyone, is removeddue toFPCpower-offor failure,multicastdiagnosticsdaemon

(mcdiagd) falls into infinite loop while collecting next-hop information. PR931380

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

• Added AI-Scripts workaround for Junos OS bug sw-ui-misc/920478 (FIPS crash).

PR932644

• If MX Series router is in increased-bandwidth fabric mode, pulling out one SCBmight

cause packets loss. PR934544

• tcp_inpcb buffer leak in ADC and TLB service pics. PR934768

• LNS drops the LCP Compression Control Protocol (CCP) packet silently comes from

L2TP tunnel. PR940784

• 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

• Egress multicast statistics displays incorrectly after flapping of ae member links on

M320 or T Series FPC (M320 non-E3 FPC and T Series non-ES FPC) PR946760

• 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

• 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, is now accounted under the

"RED-dropped" section of the CLI command "show interfaces queue". PR951235

• On systems running Junos OS Release 13.3R1 and nonstop active routing (NSR) is

enabled, when "switchover-on-routing-crash" under [set system] hierarchy is set,

Routing Engine switchover should happen only when routing protocol process (rpd)

crashes. But unexpected Routing Engine switchover can be seen when perform CLI

command "request system core-dump routing running" to manually generate a rpd

live core. PR954067

High Availability (HA) and Resiliency

• During ISSU, a message of the form: 'jnh_partition_init_mem_pools(4181):

jnh_partition_init_mem_pools: mem_top != (mem_addr + phys_size +














shared_mem_avail)'maybedisplayed(andsavedby thesyslogdaemon).Thismessage

should be ignored, the failing comparison is not valid, and thus its results can be

discarded. This comparison andmessage has no further effect on the ISSU operation.

PR848965

• During every failover of redundancy-group0, the /etc/ssh and /var/db/certs directories

are copied from the primary node to the secondary node. However, the directories are

not copied correctly and nested directories such as /etc/ssh/ssh,/etc/ssh/ssh/ssh are

created. PR878436

• If NSR 858843 switchover was done right after committing the configuration change

which deletes routing-instance(s), some of those instances will not be deleted from

forwarding table. PR914878

Infrastructure

• On TXP systemwith multicast enabled, it is advised not to deploy this release on the

system.Whenmulticast is running on amulti-chassis environment, during flapping of

224/4 or ff/8 pointing to mResolve(NH), wemight get replication error on the LCC

master causing all FPCs going offline. This flapping of resolve route for multicast can

occur because of any of the following reasons: enabling or disabling multicast, hitting

multicast table limit and deletion of resolve route, or routing restart. PR883234

• Every 10minutes kernel reports "%KERN-6:MTUfor 2001:4c0:1:1301:0:1:0:250 reduced

to 1500" after reducing MTU once. There is no impact to the system due to this

additional log message. PR888842


• On logical tunnel (lt) interfaces, youmight not be able to use the 'family vpls' option

at the [edit interfaces lt-fpc/pic/port unit logical-unit-number]hierarchy level.PR44358

• 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

• CHASSISD_SNMP_TRAP is not raised if some CLIs issued before PEM#1 is removed.

PR709293

• When you have the following configuration on a logical interface, unit 2000 {

encapsulation vlan-bridge; vlan-tags outer 40 inner-list [ 20 3000 ]; family bridge; }

And you execute "show interface intf-name extensive" you will see the below: Under

" Flags: SNMP-Traps Redundancy-Device 0x20004000 VLAN-Tag [ 0x8100.40

0x8100.200020,3000 ] ", youwill see the unit number 2000betweenouter and inner

tags configured. This is just a display issue and no functionality is affected. PR723188

• To troubleshoot a particular subscriber, one can use 'monitor traffic interface <ifd>

write-file xy.pcap'. Using this command on aggregated or demux interfaces can lead

to corrupted ingress packets in the PCAP file. Customer traffic is not affected though.

PR771447













• Collecting subscribermanagement control traffic via 'monitor traffic interfacedemux0

write-file xy.pcap', the logical unit number is incorrect whenmultiple demux IFL's are

present. This problem is fixed and the correct interface logical unit number is reported

in the juniper header of the captured PCAP file. PR771453

• Master LEDofcraft interfacekeepsGreenduringHalt thesystemorPoweroff.PR805213

• DCD reports error when configuring hierarchical-scheduler on MX80with QX chipset.

This is cosmetic error and it should not have functional impact. PR807345

• Warning message added is syslog when external sync is not supported. PR817049

• Prior to this PR, the speed of a GE interface capable of working at FE speeds was set

to 'auto' in the Packet Forwarding Engine level. This causes a problemwhenmanually

setting the speed on the Routing Engine. Now the behavior is to set the speed to '1 g'

in the Packet Forwarding Engine. For automatic speed detection the interface should

be set to 'speed auto' in the configuration. PR821512

• With Junos OS Release 11.4 or later and Enhanced SCB installed on amix of MX Series

routers with MPCs or MICs and DPC cards, REG_ERRmessages might be reported

under certain traffic flow conditions fromMXSeries routers withMPCs or MICs to DPC

card. The following syslog entry will be reported Sep 29 20:43:10 node fpc8

ICHIP(3)_REG_ERR:first cell drops in ichip fi rord : 4122 Sep 29 20:43:10 node fpc8

ICHIP(3)_REG_ERR:Non first cell drops in ichip fi rord: 7910This is a cosmetic issue that

doesnothaveanyadverseeffecton theoperationof the forwardingplane.Thesolution

for this problem is to upgrade to the Junos OS release containing a fix. PR821742

• Traffic loss is seen. Multiple inbound and outbound IPSEC tunnels are created for a

single SA during tunnel renegotiation after the lifetime expiry. PR827647

• A request(like snmp query) for collecting input ipv6 stats of ae IFL on abc chipset is

not working properly. PR831811

• Removing IP address on ATM interface after adding another IP address from the

commonsubnetcan lead toa racecondition.New IPaddressconfiguredon the interface

is still referring to shared broadcast-nexthop. Then when TCP/IP access this

broadcast-nexthop kernel, panic may happen. PR833015

• Although physical interface is disabled, reseating 1GbE SFP on MPC/MIC restores its

output optical power, hence the opposite router interface turnsUp(Near-end interface

is still down). Only 1g-SFP on MPC/MIC has the problem, but 1g-SFP on DPC/MX, EX

Series and 10G-XFP on DPC/MX don't have the problem.When the sfp is reseated,

then the sfp periodic is going ahead and enabling the laser irrespective of the fact that

interface has been enabled or disabled. Driver needs to store the state for each sfp link

and enable laser based on that. This software problem is fixed in 11.4R7, 12.1R6, 12.2R4,

12.3R2 and later release. PR836604

• If there are several logical systems in one router, basically one logical tunnel (lt-)

interface needs to work with another lt- interface, which is peer lt- interface. If one of

themallocates aMAC address first and the other attempts to allocate aMAC address,

then panic happens since it is a reallocation which finally results in the kernel crash.

The problemmight be seen when deactivating and then activating logical systems or

renaming the lt- interface. PR837898














• AnMX Series router may have an alarm, "Fan Tray Unable to Synch" when a MPC3

with a 100GEMIC is installed. This is a cosmetic error. PR838047

• In PPPoE subscriber management environment, while subscribers login/logout, each

subscriber will use an Event Rate Analyzer (ERA) until the outcome of the subscriber

connection (whether it succeeds or fails). During a logout of a high number of

subscribers (e.g. 16k), all theERAeventsarequickly exhausted (thereare 1250 in total),

so that new logins are blocked until ERA events start to be freed. PR842935

• For RE-S-1800 Routing Engines, if sysctl variable machdep.bootdevs is changed from

machdep.bootdevs=usb,compact-flash,disk1,disk2,lan to machdep.bootdevs=disk1

and router is rebooted router may go to db prompt. Problem is not triggered if more

than 1 device is listed on boot-list. To recover, the RE can be power-cycled and during

reboot press F2 to go to BIOS setting. From Boot menu select "Next Boot Device"

compact-flash and Save & Exit. After router is successfully rebooted from

compact-flash machdep.bootdevs value can be reset to default setting by "sysctl -w

machdep.bootdevs=1". PR843931

• When packet has to be forwarded over next-hop topology unilist->indirect->indexed

andwhen the packet size is greater than egress interfaceMaximumTransmission Unit

(MTU) with do not fragment (DF) bit set, then themessage of "frag needed and DF

set" sends failed. PR844987

• In a scenario of PPP sessions over L2TP tunnels, on L2TP network server (LNS), if

authentication is none or if authentication is enabled but radius does not return any

Framed-IP-Address/Framed-Pool, jpppd process is not setting the IP address key of

subscriber to "255.255.255.254" thereby resulting in address allocation failure in authd

process. Then theL2TP tunnels cannotbeestablished, hence subscribers cannot login.

When issue happens, the following logs of authd process could be seen: client type

jpppdclient typeREQUESTING:OldStyle0OldStyleFilled0hint null networknull client

pool name.PR849191

• Tx and Rx Spanning-tree BPDU stopped intermittently during ISSU. PR849201

• The device configuration daemon (dcd)may crashwhen a partial demux subinterface

configuration is attempted to be committed. There is no impact to traffic forwarding

but before the configuration can be committed, it must provide a valid

'underlying-interface' for the demux subinterface. PR852162

• Whenever tunnel interface -pe/-pd got created using theMS-DPC instead of theMPC,

it will not be able to process register messages. Because MPC and MS-DPC have

different multicast architectures and they are incompatible if chassis is configured in

"enhanced-ip" mode this issue will be seen. Necessary changes has beenmade to

code so that these interfaces will not be created on MS-DPC. PR853995

• SDG : After rebooting both Routing Engines together, the FPCs and MS-DPCsmay

come online, go offline (with "Chassis connection dropped" and "Chassis Manager

terminated" error messages) and come back online again automatically. This issue is

seen only when both Routing Engines are rebooting at once. There is exactly one

additional reboot of the FPCs when this happens, and the FPCs come back up online,

and system stabilized by itself within 2 to 3 additionalminutes [PR/854519: This issue

has been resolved in 12.1X43.3] PR854519












• In certain topology set up such as multiple trunks are used on a PE with P and the

CE-PE interface is MLFR, and enhanced-ip and MS-DPC route-localization are

configured, if the active trunk FPC is offlined, VRF traffic fromPE towards CE using the

mlfr interface may get blackholed. PR854623

• Multicast packets received by RLSQ interface on MS-DPC (TDM-to-IP direction) are

dropped with network-services enhanced-ip knob enabled. PR856535

• Onthe followingMIC-3D-20GE-SFPonly, if the 1GE interface isput into loopbackmode

all packets larger then 306 Bytes are truncated on thewire. The solution is to bring the

interface down once loopback is configured, to prevent truncated packets to be sent

out. PR856892

• In PPPoE subscribermanagement environment, PPPoE daemonmay crash and dump

core in following twoscenarios: 1 - Firewall Filter/Policer is not configuredonBroadband

Remote Access Server (BRAS) side, and AAA pushes the filter name in "Ingress Policy

Name/EgressPolicyName"whichwill expire the lockout timerwaiting tocreate required

dynamic interface, and eventually causes pppoed process crash. 2 - When IPv6 only

capable modem is trying to connect and the configuration does not contain IPv6

dynamic configuration; i.e. under PPPoE dynamic profile/family inet6 stanza; PPPoE

dynamic profile/protocols/router-advertisement, this will again expire lockout timer

waiting for dynamic interface creation, which crashes pppoed process. PR859000

• When flapping one side of PPP link, the other side of the link will fail to respond with

LCP Conf-Request, and the interface is not coming up. If the link is between PE and

CE, traffic will get lost. PR859773

• Whenapppoesubscriber sendsa 'LCPConfigure-Request'messagewithconfiguration

option 'Authentication Protocol PAP', MX BNG responds with 'LCP Configure-Ack',

instead of rejecting it with 'LCP Configure-Reject'. After sending LCP 'Configure-Ack',

BNG continues by sending 'PAP Authenticate-Request', with blank 'Peer-id" and

'Password'. This makes MX BNG behave like a client on PPP Session. Since MX BNG

is always supposed to have a Server role in PPP Session, it must respond with LCP

Configure-Reject, whenever it receives LCP Configure-Requests with 'Authentication

Protocol' option. PR860089

• Enables maximum-links CLI knob which specifies the maximum number of links in an

aggregated Ethernet bundle. This can take a value of 16, 32 or 64 depending on the

platform. PR860152

• In scaled MXVC environment, AE interfaces may get removed from the Kernel after

the GRES switchover. PR860316

• ISSU does not support VRRP. PR862052

• MX Series is sending RADIUS Acct-Start, in spite of the fact that IPCP/IPv6CP is not

established. PR867084

• ’Dump-on-flow-control’ knobmight not work correctly for RSP interfaces configured

in ’warm-standby’mode.After anRSPswitchover, eithermanually or followingacrash,

the ’dump-on-flow-control’ flag might get cleared from the MS-PIC. PR867394

• snmpwalk of "jnxPPPoEIfLockoutTable" did not capture pppoe locked out clients.

PR869024















• Chassisd core generated on initializing process on MX-VC. PR870457

• MC-LAGwill no longer change just the LACP System Identifiers directly, but will also

remove the "Synchronization, Collecting, Distributing" bits from the Actor State bits

advertised in the PDU. PR871933

• chassisd crash when enable route-localization with MPC2E. PR872500

• When Address-Saving is enabled, LCP Protocol-Reject may contain incorrect

information in "Rejected" information. The "Rejected" information SHOULD contain

the copy of rejected packet, and this has bas been fixed nowwith this PR. PR873214

• OnMX Series router with MPCwith 20port GE MIC, interface stores packets when

disabled and transmits stored packets after enabled. PR874027

• If IPv6CP is not in OPENED State, no IPv6messages are supposed to be sent on the

session. Regardless of this, MX Series is sending ICMPv6 Router Advertisement and

DHCPv6messages. PR877131

• The eepromSFP-Type descriptor has been updated to display different unique values

for fixed-rate or tri-rate copper SFPs. Going forward, the model SFP-1GE-T shows as

"1000BASE-T Copper SFP" while model SFP-1GE-FE-E-T shows as "Tri Rate Copper

SFP". PR877152

• Ethernet OAM: Ethernet Loopback test can only be performed if MAC DA is known in

the MAC table. PR879358

• In subscriber management environment, with dynamic-profiles configured for

subscribers, if the routing instance returned from radius is not configured on BRAS,

dynamic-profile add fails and there are some places the memory not freed, causing

device control daemon (dcd)memory leak. Thememory usage of dcd process can be

observed by following command: user@router> show system processes extensive |

match dcd PID USERNAME THR PRI NICE SIZE RES STATE TIMEWCPU COMMAND

7076 root 1 97 0 1047M 996M select 6:05 2.88% dcd PR880235

• MX Series router is not passing transit IPv6 traffic received on a RLSQ interface with

fib-localization enabled. PR880245

• Ethernet OAM: Invalid LBMs are not discarded by the target MEP. PR880513

• VC-Boot loop when installing new local backup Routing-Engine.PR881906

• Problem scenario: CFM UPMEP for Bridge/VPLS is configured on MPCwith action

profile as 'interface down' Problem statement: When the CFM sessions go down due

to network outage at the core, action profile is triggered and configured interface is

brought down.When the Core network failure is corrected, CFMwill not automatically

recover because interface will continue to remain down. PR884323

• "Link down" alarms should never exist on the VC Protocol Backup Routing Engine.

They should only be on Protocol Master, if any. The bug is that the "Link down" alarms

arenot cleared fromtheProtocolBackupafter/duringaGRESevent. Restartingalarmd

removes these alarms from the Protocol Backup. PR886080

• To configure FEC thresholds via CLI, use string format with mantissa and exponent:

Example: set interfaces et-1/0/0 otn-options signal-degrade

















ber-threshold-signal-degrade 1.23E-4 set interfaces et-1/0/0 otn-options

signal-degrade ber-threshold-clear 2.34E-5 PR886572

• On LAG interface gratuitous ARP is neither generated nor sent out upon link up even

when gratuitous-arp-on-ifup is configured. PR889851

• In dynamicPPPoEsubscribermanagement environment,whenMS-DPCcard is added

and"adaptive-servicesservice-package laryer-2" is configured,whilePPPoEsubscribers

login, kernel might encounter amemory corruption, causing kernel to crash and dump

core. PR894440

• The C-LMI (Consortium LMI) is supported on all i-chip based FPC. Support for the

MX-FPC 2 and 3 wasmissing and is now added. PR895004

• Following is thedocumentchangeproposed :- traceroute-ethernet-command :-Source

MAC address : MAC address of 802.1ag node responding to the LTM Next-hop MAC

address: MAC address of egress interface of the node where LTMwould be forwarded

show-oam-ethernet-connectivity-fault-management-linktrace-path-database-command

:-SourceMACaddress :MACaddressof802.1agnode responding to theLTMNext-hop

MAC address: MAC address of egress interface of the node where LTMwould be

forwardedThedisplayofNext-hopMACaddress is incorrect for linktracepathdatabase

command & this issue is fixed in mentioned release. PR895710

• In Point-to-Point Protocol over Ethernet (PPPoE) scenario, if some PPPoE session

was added and deleted, after performing Routing Engine (Routing Engine) switchover

operation, the Broadband Remote Access Server (BRAS)might fail to allocate PPPoE

session IDs on interFace Descriptor (ifd). PR896946

• IPv6 IIF-index load-balance works unwantedly when IIF-V4 is enabled alone and vice

versa. PR898676

• Reboot after panic: xe-0/1/0: bitstring index 7 not empty for 01:00:5e:00:00:01 (fix

needed for MPC/MIC) PR905417

• NPC crash seen while verifying Inline Jflow in both RE0 and RE1 and do switch over 10

times and verify new fields are updated properly. This is a software bug which have

been fixed in 12.3R5. PR905916

• Routers do not always process the first LCP request for a static PPPoE subscriber.

PR908457

• CGNAT/ADC/TLB traffic takes a Dip of ~40 sec on SDG2, after SDG1 joins the network

after becoming service-wait with Reboot. Work around is to Set the hold-time to 2

mins for all themember links of AE bundles. The result looks validate the fabric lagging

on the interface up theory. Sample member link configuration looks like, xe-0/0/3 {

hold-time up 120000 down 10; } PR918324

• Non-Existent leg in AE bundle prevents DHCP subscribers from coming up. PR918745

• 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















https://prsearch.juniper.net/PR921254

• In MX-VC environment, if LT interface's encapsulation type is ethernet-ccc, after

rebooting FPCwith LT interfaces or rebooting system, the LT interfacemight not come

up again. PR922673

• ISSU fails on upgrade to 11.4R5.7. with the following message Loggedmessages: MIC

4/0 will be offlined (In-Service-Upgrade not supported) MIC 4/1 will be offlined

(In-Service-Upgrade not supported)Do youwant to continuewith these actions being

taken?[yes,no] (no) yeserror: /usr/sbin/indb failed, status0x200error: ISSUAborted!

Chassis ISSU Aborted ISSU: IDLE Issue happens when a MIC-3D-4OC3OC12-1OC48

card is offline via cli and removed from the chassis prior to the ISSU. PR923569

• When the remote device is using Address and Control Field Compression (ACFC) PPP

compression, routers will drop the received specific packet as they are not able to

locate the PPP header. This causes L2TP sessions not getting established. PR926919

• In PPPoE subscriber management environment, when PPP daemon is receiving an

LCPpacketwith an invalid code ID andwithout any option, jpppdprocess crasheswith

a core file generated. PR929270

• This is a day-1 issue.When amember linkwas added to or removed froman aggregate

bundle like AE on a dual RE sytemwithout GRES, Kernel in the backup Routing Engine

would crash due to assertion failure in the function

rt_pfe_nh_cont_nh_decrement_ack_count. PR935729

• Traffic is not flowing over Demux input interface. A technical description can be found

in the Knowledge Base: http://kb.juniper.net/KB28821.PR937035

• In an MX Series router, multicast traffic may not be forwarded to the "Downstream

Neighbors" as reported by the command "show pim join extensive". There can be

occasionswhere this traffic is blackholedandnot forwardedasexpected.Alternatively,

there may be an occasion where multicast traffic is internally replicated infinitely,

causing one ormore of the "DownstreamNeighbors" to receivemulticast traffic at line

rate. PR944773

• When transit traffic of Ethernet frames of size less than 64 bytes are received by 1x

10GE(LAN/WAN) IQ2E PIC, the router forwards the frames instead of dropping

them.PR954996

Layer 2 Features

• Whendirectly applying samplingonVPLS interface (i.e interfacege-4/0/1 unit 0 family

vpls sampling input), if customerconfigures logical interfaceandsampling input/output

together first time, then deactivating sampling input/output through CLI, kernel will

then not disable the sampling. Also note that, the action of sampling is a hidden

command for VPLS interfaces and would not be listed in "possible completion" list

when combined with "?". PR772270

• OnMXSeries routerswithMPCsorMICsafter thechangesperformedwithinPR/686399

Junos OS Release 10.4R9 or later, traffic destined towards mac addresses learned

from the core interfaces are aged out every aging interval and added again. During this

very short event, VPLS traffic will get flooded. PR820726













• In VPLS environment, while deactivating/activating VPLS routing-instances, in rare

conditions, routingprotocoldaemontries to freeanalreadyused route, then rpdprocess

crashes with core files dumped. PR908856

• InBGPautodiscovery forLDPVPLSscenario, asFEC129VPLSdoesnotsupportNonstop

active routing (NSR), VPLS fails to come up after Routing Engine swichover and traffic

will never resume. PR919483

• ==========BACKGROUND==========AglobalGRES,whichwill causeamaster

Routing Engine to transition to backup, WILL require all Kernel state to be cleaned so

that it can start a fresh resync from the newmaster. Ksyncd is tasked with cleaning up

Kernel state. On cleaning routing tables, if any table has a non-zero reference count,

itwill return "DeviceBusy" to the ksyncd. Ksyncdwill try 5 successive cleanupattempts

after which it will trigger a live Kernel core. ======= PROBLEM ======= In ksyncd's

kernel cleanup, the Bridge Domain mapped to a VPLS routing table is deleted AFTER

anattempt ismade todelete the route table. This is a catch-22 sinceBDshold reference

counts to the routing table. ===== FIX ==== Cleanup of VPLS routing tables should

proceed bottom up in the following order: NextHop Deletes, User Route Deletes,

Interface Deletes(ifd,ifl,iff), STP Deletes, Bridge Domain Deletes, Mesh Group Deletes

and finally Routing Table delete. This ensures thatwhenwe get to routing table delete,

all dependencies, that could hold a ref cnt to the routing table, are nowgone.PR927214

Layer 2 Ethernet Services

• Traffic loss after performing graceful Routing Engine switchover (GRES). There are

two similar problems fixed here: 1. In the rare case, after the first GRES, some IPv6

routes are failed to be added because the buffer to Routing protocol daemon (rpd) is

full and thus the response to the add request is failed. 2. Somewhile, when one GRES

is performed after another GRES, some IPv4 routes are failed to be added because

the logical interface is not up yet and the Next-hop address isn't populated timely.

PR808932

• jdhcpd interface traceoptions are not saved to the default log file jdhcpd and require

an explicit file name. PR823129

• It can happen that when changing an interface framing from lan-phy (default) to

wan-phy and back a few times, the interface doesn't show up anymore in "show

interfaces terse". PR836382

• In DHCP relay scenario, some DHCP relay bindings might get stuck in

"RELEASE(RELAY_STATE_WAIT_AUTH_REQ_RELEASE" state due to the LOGOUT

Request is not processed correctly by authentication manager process (authd) and

this causing clients are not able to get a lease. PR850187

• In certain caseswhen theMXSeries router is configuredasDHCPv6server andservicing

DHCPv6 clients through LDRA relay, it may send advertisements with UDP port 546

instead of 547. PR851642

• ForMXVC, the derivation of the dhcp server-id has changed fromusing hardware serial

number to lacpmac addr. The reason is that the lacpmac address is guaranteed to

be reflected across the chassis so upon GRES, the same dhcp server id can be built.

However, upon ISSU, theold softwarewill derive server-id fromhardware serial number

and the new software will derive it from lacpmac address and they will not match.











After the ISSU, DHCP packets may be dropped by a dhcp server because the serverid

in the client packet will not match that of the server. This will only happen when

transition to the newmethod of building the serverid. Once that has happened, all

future ISSU should work as before. PR853329

• In DHCP subscriber management environment, while DHCP subscribers login, in rare

conditions, system calls of these subscribers fail, due to only on success does system

free the memory, resulting in a memory leak for the jdhcpd process. If memory usage

of jdhcpd process goes to its limit, no new DHCP subscribers can login. When issue

happens, high weighted CPU usage of jdhcpd process and following logs could be

observed. /kernel: %KERN-5: Process (31403,jdhcpd) has exceeded 85% of

RLIMIT_DATA: used 2825132 KBMax 3145728 KB jdhcpd:

%USER-3-DH_SVC_RTSOCK_FAILURE: Error with rtsock: rtslib: ERROR Failed to

allocate newblock of size 16384 jdhcpd:%USER-3-DH_SVC_RTSOCK_FAILURE: Error

with rtsock: rtslib: ERROR Failed to allocate new block of size 16384 jdhcpd:

%USER-3-DH_SVC_RTSOCK_FAILURE: Error with rtsock: rtslib: ERROR Allocation

Failure for (16384) bytes authd[1822]: %DAEMON-3:

../../../../../src/junos/usr.sbin/authd/plugin/radius/authd_plugin_radius_module.cc:1090

Failed to get SDB snapshot for session-id:3549005 PR856024

• WhenDHCPv4 relay is configuredonan IntegratedRoutingandBridging (IRB) interface

with both IPv4 and IPv6 families configured,when remove "family inet6" configuration

from the IRB, DHCPv4 relay function broken. This happens regardless of whether the

"family inet6" is configured directly under the IRB or applied through an "apply-group"

configuration. In versions that do not have the fix for this PR, the workarounds to get

the dhcp relay functionality working again over the IRB are *either* of the following:

1) Deactivate/activate the IRB configuration. 2) Restart dhcp daemon using the

following command. user@host> restart dhcp-service PR870543

• "show bridge mac-table interface X vlan-id Y" is empty on trunk port. This is just a

display issue. This MAC is present on the forwarding table that can be confirmed using

command "show route forwarding-table family bridge". PR873053

• MX Series router does not provide DNS server information in response to DHCPv6

Information-Request. PR874423

• When IPv6 is configured on integrated routing and bridging(IRB) interfaces that have

AE interfacesaschild links, afterGRESwasenabledandonechild link failureor removal,

the kernel crashed. PR878470

• DHCPv6Local Server implementationdeletes the client ona reconfigure, so that client

can reconfigure. DHCPv6 relay is not forwarding the Reply to the client and simply

tearing the client down (generating a release to the server). PR879904

• If STP is configuredonAE interface, the l2cpdmight beunder highutilizationandVRRP

repeatedly flaps after the VRRP active router reboots. The root cause here is when

STP is configuredonAE interface, thecorrespondingBridgeProtocolDataUnit (BPDU)

messages will go to Routing Engine (Routing Engine) instead of processed in Packet

Forwarding Engine ( Packet Forwarding Engine). PR882281

• When executing "show dhcp relay binding" command with high scales of bound

subscribers andwith several hundred renewing at a given time, DHCP drops the renew

packets. PR882834












• In MX Virtual Chassis (MXVC) scenario, under high scale system environment (many

Aggregated Ethernet interfaces, many logical interfaces), after performing global

graceful Routing Engine switchover (GRES) by CLI command "request virtual-chassis

routing-engine master switch", the Link Aggregation Control Protocol (LACP) state of

access Link Aggregation Group (LAG) interface might change and therefore result in

traffic loss. PR885013

• In an IP demux/vlan demux configuration, where the primary address for the loopback

is different from the preferred in the dynamic profile, the ACK to the first RENEWwill

have the theprimaryaddress in loopbackas server ID sinceRENEWarriveson ipdemux

interface. The clientwill send the next RENEW to that server ID and the routerwill drop

it. The fix is to always use the server ID from the underlying interface. PR890562

• It has been observed that MX Series router might not reply to re-transmitted DHCPv6

Solicit and Request messages. This has been addressed by PR and the behavior has

been changed, in order for theMXSeries router to be able to reply to all re-transmitted

DHCPv6 packets. PR900371

• JDHCPD-DHCP local server sends incorrect option-54 used in ACK during lease

renewal.PR915936

• InEthernet ringprotectionscenario, uponFPCreboots theSTP indexwill getmis-aligned

causing traffic drop. when this issue occurs following message can be seen. Before

FPC restarts: user@router> show protection-group ethernet-ring vlan Ethernet ring

IFBD parameters for protection group Ring1 Interface Vlan STP Index Bridge Domain

xe-5/3/0 302 222 default-switch/v302 xe-0/2/0 302 223 default-switch/v302

xe-5/3/0 308 222 default-switch/v308 xe-0/2/0 308 223 default-switch/v308 After

FPC restarts: user@router> show protection-group ethernet-ring vlan Ethernet ring

IFBD parameters for protection group Ring1 Interface Vlan STP Index Bridge Domain

xe-5/3/0 302 245 <<<< default-switch/v302 xe-0/2/0 302 223 default-switch/v302

xe-5/3/0 308 222<<<<default-switch/v308 xe-0/2/0 308 223 default-switch/v308

PR937318

• Service accounting interim updates not being sent. PR940179

• In DHCP relay scenario, some DHCP relay bindings might get stuck in

"RELEASE(RELAY_STATE_WAIT_AUTH_REQ_RELEASE" state due to the LOGOUT

Request is not processed correctly by authentication manager process (authd) and

this is causing clients not to be able to get a lease. PR945035

• The RSVP bandwidth of the 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


• 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

• Unsupported feature warning missing for mLDP+NSRwhile doing ISSU. PR849178

• In an RSVP environment with AutoBw, the Bandwidth Adjustment timer for new LSPs

added simultaneously is not smeared along with the rest of the existent LSPs when

the smearing algorithm is triggered. PR874272














• In a scenario where scaled MPLS tag labels exist, while MPLS flapping (which could

be triggered by routing protocol flapping), routing protocol daemon (rpd)might crash

and generate a core file due to the system trying to delete an already freed MPLS tag

label Element. PR878443

• WhenBGP labeled-unicast routehasBGP label asnull and its indirectnext-hop requires

adding 2 or more labels, traffic using the BGP label may not be forwarded properly.

PR881571

• With OSPF overload enabled, the te-metric will be set as 2^32, and the Constrained

Shortest Path First (CSPF) process ignores the path with metric value 2^32, with the

result that the ingress LSPs cannot come up. PR887929

• In current Junos OS, lsping/lsptrace utils have compatibility issue with other vendor

routers. millisecond field might show huge value which results in incorrect RTD

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

• RPDmight crash after executing "ping mpls l2vpn interface <interface>" command

under specific time window. PR899949

• When a First hop LSR is sending Resv Message with non-directly connected IP as next

hop (in Resv HOP object), Junos OS on head end will try to install this in forwarding

table. As the next hop to be used is a non-directly connected address, forwarding table

update will fail with following KRT_Q_STUCKmessage: RPD_KRT_Q_RETRIES: Route

Update: Invalid argument PR920427

• The output of "show ldp overview" command regarding graceful restart is based on

per protocol LDPgraceful restart settings.Where graceful restart is enabledby default.

Sowhengraceful restart is disabled this commandshows it's enabled for LDP.However

graceful restart shouldbeenabledglobally for LDPgraceful restart tooperate.PR933171

• On ISIS 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 LDP

adjacency times-outafter thenewLDPadjacency is up, the ISISprotocolwill benotified

about old LDP adjacency down event and the LDP sync statewill remain in hold-down

even if the new LDP adjacency is up.PR955219

• 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. Issue is planned to

be fixed in later versions. PR956661

• RPD generated a core file due to LDP failing to delete a job that didn't exist while

shutting down.PR968825













NetworkManagement andMonitoring

• Removed empty mib file "mib-jnx-jnw.txt" from the JuniperMibs directory.PR800134

• Mib2dmaygetATMVPIupdatesbefore theATM IFDsare learned. In suchcases, instead

of discarding the updates, mib2d has started caching them until the IFD is learned.

PR857363

• SNMPquery fromvalid client on routing-instance-1with community string thatbelongs

to routing-instance-2 gets the details of routing-instance-2 instead of blocking such

queries based on community. PR865023

• The results from SNMPMIB get of hrMemorySize does not correspond to any Junos

OS CLI output. PR873665

• While some set operation is in progress, there is a huge pile-up of pending requests in

netsnmp_agent_queued_listQueue.,which is running intoseveral thousandsof requests

which is causing the memory consumption to increase in snmpd and running out of

256 MB of rlimit and crashing. PR920471

• Digital Optical Monitoring MIB jnxDomCurrentRxLaserPower gives wrong value in

12.3R3-S6. PR946758

Platform and Infrastructure

• On the process details page (Monitor > System View > Process Details) of the J-Web

interface, there are multiple entries listed for a few processes that do not impact any

functionality. PR661704

• WhenanMS-DPCPIC reboots due to a crash ormanual intervention, itmight get stuck

in a booting loop if the MS-DPC up-time is more than 49 days and 17 hours. After 5

consecutive boot failures, the MS-DPC PIC will go offline automatically and gives the

following error message: [ 15:21:22.344 LOG: Err] ICHIP(0): SPI4 Training failed while

waiting for PLL to get locked, ichip_sra_spi4_rx_snk_init_status_clk [ 15:21:22.344 LOG:

Err] CMSPC: I-Chip(0) SPI4 Rx Sink init status clock failed, cmsdpc_spi4_init [

15:21:22.344 LOG: Err] CMX: I(0) ASIC SPI4 init failed [ 15:21:22.379 LOG: Err] Node for

service control ifl 68, is already present [ 15:21:23.207 LOG: Err] ASER0 SPI-4 XLR

source coreOOFdid not go low in 20ms. [ 15:21:23.208LOG: Err] ASER/XLR0spi4 stop

src train failed! [ 15:21:23.208 LOG: Err] ASER0 XLR SPI-4 sink core DPA incomplete

in 20ms. [ 15:21:23.208 LOG: Err] ASER/XLR0 spi4 sink core init failed! [ 15:21:24.465

LOG: Err] ICHIP(0): SPI4 Stats Unexpected 2'b 11 Error, isra_spi4_parse_panic_errors [

15:21:24.465 LOG: Err] ICHIP(0): SPI4 Tx Lost Sync Error, isra_spi4_parse_panic_errors

In order to recover from this state thewholeMS-DPCneeds to be rebooted.PR828649

• Since the AC Power System onMX2020 is a N+N feed redundant and N+1 PSM

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 an interface is configured as trunk port the Interface bridge domain (IFBD)

features needs to be executed before Logical interface (IFL) features. This is missing












for logical tunnel (lt)-interfaces and the packets where discarded in the Packet

Forwarding Engine as unknown family. PR832941

• In L2circuit or L2vpn scenario, when knob "indirect-next-hop" is enabled and route

change which is using indirect nexthop, the memory might not be freed. This might

lead tomemory leak and corruption, so that packet forwarding will be affected. When

the issue happen, the following logs will be seen: Resource Category:jtree

Instance:jtree0-seg0Type:free-dwordsAvailable:103808 is less thanLWMlimit:104857,

rsmon_syslog_limit() Resource Category:jtree Instance:jtree0-seg0 Type:free-pages

Available:1625 is less than LWM limit:1638, rsmon_syslog_limit() PR833472

• Due toabug in IFL localization, aDPC restart/offlinemay causea removal of legitimate

CCC routesonotherDPC's. This canalsobe triggeredby removal of anunrelated family

CCC logical unit. PR835216

• Added support for "raise-rdi-on-rei" knob on FPCs on MX Series and T Series routers.

PR844097

• Fabric drops and Normal discards counters among other counters under "cli > show

pfe statistics traffic" could increment despite no actual drops. This issue could be

experienced after an unexpected FPC reload or combination of fabric planes

offline-online events. The same counters that are seen incrementing on the

CLI/Routing-Engine when queried under all FPCs would show them as not increasing.

Hence this confirms this to be a cosmetic bug that only affects CLI output counters.

PR846011

• Maximum power required for SFBs is changed from 250W to 220W. Maximum power

required for 172mm Fan Trays is increased from 1500W to 1700W. The power

requirement for MX2010's upper fan trays is not changed. It is still 500W.With this

change, the Reserved Power for critical FRUs (CB/RE, SFB and FanTrays) changes

from 7000W to 7360W for MX2020 and from 6500W to 6660W for MX2010.

PR848358

• When the FIB-local FPC offline, FIB-remote MS-DPCwas still sending some traffic to

it resulting in traffic loss. PR851605

• OnMX Series routers, with some logical interfaces of an aggregated Ethernet (AE)

interface attached to a bridge-domain and LACP is enabled on the AE interface, after

disabling/enabling or removing/adding one or more member links of the AE interface,

because the receive channel of the AE interface is closed when LACP state is down,

traffic loss might be observed for several seconds. PR858124

• Once ingress queuing is enabled on MX Series routers with MPCs or MICs, L2 control

traffic had no default classifier assigned and used best-effort queue. Under queue

congestion, L2 control traffic like IS-ISmight get behind and trigger an adjacency flap.

L3 control traffic and MPLS control traffic are not affected. PR858882

• This issue is specific toMPC3andMPC42. This is related to sending out export packets

andwill be seenwith both ipv4/ipv6 inline jflow sampling. This issuewill be seenwhen

flow export packets are sent out at high rates. Once themessages start appearing,

they cannot be suppressed as they are flagged as ERRORmessages.There is no known

impact on data traffic and export packets because of these messages. PR861012













• When an MX Series router collects with inline jflow, exported IPv6 UDP packets show

UDP checksum is incorrectly set to 0x0000. Which might be discarded by received

node. 12:19:11.513058 In IP6 (hlim 64, next-header: UDP (17), length: 138)

2001:db8:ffff:ffff::20.33068>2001:db8:0:100::101.2055: [badudpcksum9652!]UDP,

length 130 12:19:11.524964 In IP6 (hlim 64, next-header: UDP (17), length: 138)


length 130 12:19:16.509978 In IP6 (hlim 64, next-header: UDP (17), length: 138)


length 130 PR870172

• Whencheck trace route, RSVP-TEProbestatus is not shownas successand It is shown

as unhelpful. Note :seeing this issue with enhanced-ip mode and not seeing this issue

without enhanced-ip in same setup and same image. PR871015

• In the Network Time Protocol (NTP) configuration, if the specified source ip address

is not in current routing-instance, the routerwill useprimaryaddressof interface (which

will beused tosendpacket)assourceaddress,Client routerswill treat theNTPpackets

as incorrect packets, and then NTP synchronization failed. PR872609

• OnMXSeries routerswithDPC(ICHIPbased) typeFPCs runninga 11.4 (or newer) Junos

OS releasedisablinguRPFona logical interfacemight result inanother logical interface

on the router to drop all incoming packets. This problem happens only when the

following conditions are met concurrently: a) 2 different logical interfaces share the

same lookup index b) both logical interface have uRPF enabled c) these 2 different

logical interfaces belong to 2 different FPCs d) at least one of the logical interfaces

belongs to a DPC (ICHIP based) type FPC The lookup index is calculated by taking the

lower 16 bits of the logical interface index (also called the IFL index). In other words

lookup index = IFL index MOD 65536 . It is normal, valid and expected to have logical

interfaces which share the same lookup index. The problem described in this PR is

_not_ the fact that the lookup indexes are the same. Here is an example of 2 different

logical interfaces on 2 different FPCs which share the same lookup index: Interface

ge-0/1/0.945 has an IFL index of 1774 and a lookup index 1774: user@router-re1> show

interfaces ge-0/1/0.945 Logical interface ge-0/1/0.945 (Index 1774) (SNMP ifIndex

1635) ^^^^^^^^^^Flags:Device-DownSNMP-Traps0x4000VLAN-Tag [0x8100.945

] Encapsulation: ENET2 Input packets : 0 Output packets: 0 Protocol inet, MTU: 4462

Flags: Sendbcast-pkt-to-re, uRPF, uRPF-loose Addresses, Flags: Dest-route-down

Is-Preferred Is-Primary Destination: 52.3.168.216/29, Local: 52.3.168.217, Broadcast:

52.3.168.223 Protocol multiservice, MTU: Unlimited And interface xe-2/2/0.0 has an

IFL indexof 198382anda lookup indexof 198382MOD65536=1774:user@router-re1>

show interfaces xe-2/2/0.0Logical interfacexe-2/2/0.0 (Index 198382) (SNMP ifIndex

698) ^^^^^^^^^^^^ Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2 Input

packets : 381Outputpackets: 376Protocol inet,MTU: 1500Flags:Sendbcast-pkt-to-re,

uRPF, uRPF-loose Addresses, Flags: Is-Preferred Is-Primary Destination:

155.154.153.0/30, Local: 155.154.153.1, Broadcast: 155.154.153.3 Protocol multiservice,

MTU: Unlimited In the example above if uRPF is disabled on ge-0/1/0.945 then

xe-2/2/0.0 will start dropping all incoming packets due to RPF failure. When this

condition occurs the only way to recover is to disable, commit and re-enable uRPF on

the broken interface. When this is done the following error messages are generated:

Apr 15 16:02:53 router-re1 fpc2 rt_iff_generic_topo_handler: jtree error Not found for

disconnecton iff-post-srcApr 15 16:02:54 router-re1 fpc2RT(rt_rpf_jtree_drt_remove_ifl):






Unable to remove ifl 198382 from drt(4) Apr 15 16:02:54 router-re1 fpc2

RT(rt_rpf_jtree_drt_remove_ifl): Unable to remove ifl 198382 from loose(7) PR873709

• In FPC interconnectionwith FPC type5orMPC3E scenario, traffic loss about 2 seconds

during interface up. PR874659

• OnMX Series routers with MPCs or MICs after repeated firewall filter delete/change

operations (whichmay occur with interface flaps, e.g.), memorymight leak which can

cause ASICmemory exhaustion, causing MX Series routers with MPCs or MICs line

cards to crash and generate core file. PR875276

• MPCmight crash during unified in-service software upgrade (ISSU) if inline-jflow table

size is configured. PR876258

• If interface flapsofabridge-domainwith igmp-snoopingenabledormulticast snooping

routes are pruned due to Designated Router changes, LUCHIPmight report traps and

EDMEM read errors. These conditions are transient and only seen once the system is

operating with enhanced-ip mode. PR879158

• InDHCPrelayagentscenario,DHCPoffermessagewithoption82(relay-agent-option)

is discardedbyUDPForwardingprocess (fud)after receiving the replyback fromDHCP

server. This issue happenswhen the length of the interface name (including underlying

and parent interface) is greater than 23. For example: irb.1011/0/0.1011 - 22 characters

works irb.1011/0/0.10011 - 23 characters fails. PR886463

• While configuringa filterwithagenericprefix followedbyspecific one indifferent terms

may lead to incorrect match, this might lead to packet drop. PR886955

• When a router is acting as an NTP broadcast server, broadcast addresses must be in

the default routing instance. NTPmessages are not broadcast when the address is

configured in a VPN routing and forwarding instance (VRF). PR887646

• It is observed that in the setup route nexthop for destination of collector's IP address

was of type indexed nexthop. PR889884

• In L2/3VPN and label-switched paths (LSPs) scenario, when a packet goes through

an LSP which is over an aggregated Ethernet (AE) interface with member links across

multiple MX Series routers with MPCs or MICs Packet Forwarding Engines ( Packet

Forwarding Engines), the packet is getting corrupted when one Packet Forwarding

Engine is imposingVPN labelon thepacketandsending it toanotherPacketForwarding

Engine for LSP label imposition. As a result, the packet is dropped at the remote PE as

"normal discard" finally. PR892704

• OnMX Series routers with MPC, firewall filter counter doesn't count packets when

firewall is configured on discard interface. PR900203

• Configuration of scheduler with zero guaranteed rate and excess priority none is an

invalid class of service configuration but is allowed by CLI. When this is configured, the

packet enqueued in the corresponding queue will not be able to be transmitted.

PR900239

• OnMX Series platforms running Junos OS Releases 12.3R3, 12.3R3S1 and 12.3R3S2,

interfaces with interface-mode trunk connected on top Packet Forwarding Engine[0]

and with Integrated Routing and Bridging (IRB) interfaces might corrupt

forwarding-state on lowest Packet Forwarding Engine of the FPC. This is applicable















to system operating with network-services enhanced-ipmode and systems operating

in virtual-chassis (VC) mode. PR907291

• "set chassis fabric upgrade-mode default" CLI used for during smooth upgrade of

T1600 to TXP is not working in TXP. PR908311

• After interface reset,CoS informationmaynotbeappliedcorrectly toPacketForwarding

Engine, leading to inconsistency in scheduling/shaping in Qx Chip. PR908807

• In MX virtual-chassis (MX-VC) scenario, when the VC-M (master member of VC)

reboots and then comes up, the MPCwith virtual-chassis port (vcp) configuredmight

crash due to the memory overflowed. PR910316

• When enhance-route-memory is enabled along with SCU configuration may cause

Jtree Memory corruption on MX Series routers with DPCs. PR914753

• OnMX2020, SNMP traps are generated only for SFB slot 6 and 7 upon GRES enabled

Routing Engine swithover. PR915423

• Issue observed in inline Jflow during route-record collection. For route-record function

in inline-Jflow it is expected that for any aggregated type next hops a child next-hop

must be present. This child next-hop info is updated as gateway info for aggregated

next-hop. In scenario,wherewehavevalidaggregatednexthop idbutnochildnext-hop,

system is crashing in inline-jflow during route-record collection. PR919415

• In subscriber management scenario, memory leak might occur when the firewall

fast-update-filter feature is configured, and it will impact any new subscriber login.

Suchmemory leak can be seen with following command, root@router> show chassis

fpc Temp CPU Utilization (%) Memory Utilization (%) Slot State (C) Total Interrupt

DRAM (MB) Heap Buffer 0 Online Absent 8 0 1024 70 << 13 1 Online Absent 8 0 1024

29 13 PR926808

• Under certain timing conditions the MPC/TFEB can receive the firewall filter

configuration before it is fully booted/UP/ONLINE. Because the firewall filters can

depend on certain default values which are not yet programmed the MPC/TFEB will

crash/core-dump and reboot/restart/reload. PR928713

• The jcs:dampen() function will not perform correctly if the system clock is moved to

an earlier time. PR930482

• WithMXSeries routerswithMPCsorMICs, changingMTUonone interfacemight cause

L2 traffic interruption on other interfaces in the same FPC. PR935090

• When replacing ichip FPC with MX Series FPC, "traceroute" packets going through an

MX Series FPCmay experience higher drop probability than when using an Ichip FPC.

PR935682

• On front panel display LED status for PSM is incorrect after manually Remove/Insert

of PSM. PR937400

• 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

















• 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

• In PPPoE subscriber management environment, if the BRAS router is MX Series router

with MS-DPC equipped and traffic from the subscribers is NATed on MS-DPC card,

whenPPPoEsubscribers flap,heapmemory leakmightoccurontheMS-DPC.PR948031

• 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 use for trouble shooting. For example, attribute 199 is display as

"UDMA CRC Error Count" is actually "Total Count of Write Sector". PR951277

• 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

Routing Policy and Firewall Filters

• If RPF and/or SCU is enabled then any change to an ingress firewall table filter will

trigger RPF/SCU reconfiguration for every prefix in the routing table. This may cause

transient high CPU utilization on the fpcwhichmay result in SNMP stats request being

timed out. PR777082

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 importpolicyhasanondefault setting.Asa result, damping

settings do not change appropriately when the route attributes change. PR51975

• When "passive" and "disable" knobs are both configured under [edit protocols isis

interface <inft> level <N>] hierarchy the interface is treated as "passive" instead of

being disabled. PR697553

• Continuous soft core-dumpmay be observed due to bgp-path-selection code. RPD

forks a child and the child asserts to produce a core-dump. The problem is with

route-ordering. And it is auto-corrected after collecting this soft-assert-coredump,

without any impact to traffic/service. PR815146

• EBGPmultipath failed to become activate route in some case. PR835436

• In subscriber management environment, routing protocol daemon (rpd) may crash

and generate a core file due to snmpwalk fails at mplsL3VpnVrfRteInetCidrDestType

whenasubscriber access-internal route in aVRFhasadatalinknexthop (suchaswhen

DHCP subscriber connects into a VRF). When issue happens, the following behaviors

couldbeobserved: user@router> showsnmpmibwalk asciimplsL3VpnVrfRteInetCidr

| no-more Request failed: Could not resolve 'mplsL3VpnVrfRteInetCidr' to an OID

user@router> show snmpmib walk ascii mplsL3VpnVrfRteInetCidrDest | no-more

Request failed: General error.PR840323

• Memory leak after deleting a single BFD session. PR840672














• OnMX Series routers, multiple rpd process core files might be created on the backup

Routing Engine after a nonstop software upgrade (NSSU) has been performed while

multicast traffic is on the switch. PR841848

• When a Bidirectional PIM RP is configured on a physical interface, such as fe-0/0/0,

after restarting the routing, the RPF interface might not be added to the accepting

interface list for the affected groups. PR842623

• Whenpim traceoptions "flag all" and "flag hello disabled" are configured, traces about

hello from ppmd are still seen. The work-around is to configure "flag hello detail

disabled" as well PR842627

• System cored when it is scaled with 10 k bfd sesion and Routing Engine switchover

being performed. PR843868

• Whenever a config change is made and a commit is issued, the Routing Engines CPU

utilization could go up due to BGP reprocessing all the routes, because of the commit.

This would happen for any commits unrelated to policy, bgp configuration andmost

common with scaled bgp environment. PR853670

• There is improper <route-family> tags added to all "multicast route summary"

commands when we perform command such as "showmulticast route summary |

display xml". PR859104

• If a static route was configured and exported into OSPF, and if the static route had the

same subnet as an OSPF interface address, then committing configuration changes

(even unrelated to OSPF, such as a device's hostname) resulted in the removal of the

static route related to OSPF type-5 link-state advertisement (LSA) from the OSPF

database. PR875481

• In multicast environment running PIM, when RPF neighbor changes with upstream

interface flap, the routingprotocol daemon(rpd)might crashwithacore file generated.

PR886403

• When used JUNOScript to run command 'get-pim-neighbors-information instance='

(with NULL instance name), which triggered core file even though there are no

routing-instances with pim enabled. It won't trigger core file if JUNOScript command

includes any instance name. PR887070

• In a scenario with graceful restart(GR) enabled for BGP between Cisco platform and

Juniper platform, Junos OS is helper (default) and Cisco being restarting router, when

Cisco restarts BGP process, Juniper deletes all BGP routes due to doesn't receive End

Of RIB (EOR)markers for all configured NLRI's from Cisco. PR890737

• Prefixes that are marked with 2 or more route target communities (matching multiple

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

• Sometimes "Advertised prefixes" counter for some RIBs may be incorrect for some

BGP neighbors. This is a cosmetic issue. Use "show route advertising-protocol bgp

<nbr> table <tblname> |matchNexthop | count" to know the right advertised prefixes

count. PR899180















• When the interface goes down, the direct route for that peer address is removed from

the routing table before BGP processes interface down event and bring down the

session.WhenBGPcalculatemultipath routes, since theknob"accept-remote-nexthop

knob" is configured,BGPneeds todeterminewhetherwecan reach thenexthopaddress

(ebgp peer address) directly. BGP did not find direct route for this nexthop address

and so asks for route nexthop resolution. In this case, the first BGP path from the peer

with up interface has direct router nexthop, the second path is set to have indirect

nexthop due to the down interface, BGP passed a wrongmixedmultipath nexthop,

which caused RPD crash. PR917428

• If there is an undergoing cleanup process in rpd (as a consequence of a BGP session

restart) while rpd is being re-initialized via a commit operation, the cleanup process

might not yield control to other tasks and lead to an RPD_SCHED_SLIP message.

PR928223

Services Applications

• 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 sending traffic through IPsec tunnels for above 2.5Gbps on anMS-400 PIC, the

Service-PICmight bounce due to prolonged flow control. PR705201

• Max number of supported IPsec tunnels might depend on networking activity as well.

Under heavy networking activities, while DPD (Dead Peer Detection) is enabled, the

maximum number of supported IPsec tunnels can drop to about 1800. PR780813

• The service-set configurationwas not getting added to kstate DBwhen the service pic

toggledduring configuration (If the IFD is up, but goesdownwhen the service set config

is being pushed). Since the service-set is not present in the kstate DB, even after the

PIC comes up it is not configured. PR809266

• Memory leak in key management daemon (kmd) causes some IPSec VPN tunnels to

be dropped and don't get re-negotiated for over 10minutes. Before issue happens, the

following logs could be observed: /kernel: Process (1466,kmd) attempted to exceed

RLIMIT_DATA: attempted 131080 KBMax 131072 KB /kernel: Process (1466,kmd) has

exceeded 85% of RLIMIT_DATA: used 132008 KBMax 131072 KB PR814156

• In L2TP subscriber management environment, on L2TP Access Concentrator (LAC),

L2TP tunnel idle timer is started when the last session on the tunnel is deleted, if the

tunnel idle timer expires, then L2TP keeps the tunnels/session/destinations in dying

state for the duration of destruct timer (which by default is 5 minutes (300 secs) )

before theygetdestructed.During this phase, jl2tpdprocess tries to resurrect the tunnel

in dying state, causing jl2tpd process crash and dump core. When issue happens, the

following logs could be observed: init: l2tp-universal-edge (PID 50230) terminated by

signal number 6. Core dumped! /kernel: pid 50230 (jl2tpd), uid 0: exited on signal 6

(core dumped) The impact of l2tpd process crash is, for short period of time tunneled










subscribers cannot connect while processes restarts, existing connections are not

expected to drop. The unexpected result of continues crashes (which has been found

in production andbeen replicated in the lab) is somesubscribers are left in stale states,

subscriber disconnects and reconnects but original session gets stuck on LAC in stale

state. This will cause memory jump of many different processes (e.g. authd, jpppd,

dcd, dfwd, rpd, cosd). PR824760

• When rollback from v9 to v5 is done, Sampling logic was not rolling back, as sampling

registers are not getting released from Packet Forwarding Engine and because in v5

the sampling is Routing Engine based it was not working. PR824769

• WhenMX Series uses MS-DPC to provide the tunnelling service for flow-tap traffic, if

there is SCU/DCU configured on the same slot of the flow-tap traffic ingress interface,

all the flow-tappedsampledpacketswill bedropped. It is causedby thewrongnexthop

linking when DCU is configured. PR825958

• The issue was because the configured VT interface is not stored properly in the data

structure(It was always NULL). Hence,whenever DFCD receives a SIGHUP it treats the

VT interface to be changed. PR827038

• NAPT: Packet Forwarding Engine side report port range start from 512 cause napt mib

counter wrong, this fix make the port range in pfe start from 1024. PR828450

• The jnxNatSrcNumPortInuse counter is not refreshing when polling the

jnxNatSrcNumPortInuse OID via SNMP after RSP switchover. PR829778

• In L2TP subscriber management environment, after issuing CLI command "commit

full", jl2tpd process (l2tp daemon) deletes all tunnel profiles and brings downall L2TP

subscribers. Even though there are no configuration changes. PR834504

• MAC Flow-control asserted and MS-DPC reboot is needed.PR835341

• WhenDHCP subscribers login and radius hands down flow-tap variables the following

errors are seen in the log: "/kernel: GENCFG: op 24 (Lawful Intercept) failed; err 5

(Invalid)." PR837877

• If flow-tap or radius-flow-tap is configured and logging, dynamic flow control daemon

(dfcd) may be leaking file descriptors. Over time these leaked file descriptors reach

the limit and followingerrormessagewill be seen. /kernel: kern.maxfiles limit exceeded

by uid 0, please see tuning(7). Then routing protocol daemon (rpd) may crash and

dump a core file. PR842124

• 1) corrected the log to state 4 bundles per tunnel to have been exhaused. 2) change

the log level from INFO to DEBUG 3) Addmore context to previous log: New IPSec SA

install time 1356027092 is less than old IPSec SA install time 1356027092 new log =

Tunnel:<tunnel-id> <Local_gw>: <local-gw-ip-addr> New IPSec SA install time

1356027092 is less than old IPSec SA install time 1356027092 4) addedmore context

to previous log: SA to be deletedwith index 3 is not present new log = SA to be deleted

with index 3 is not present <Local_gw>: <local-gw-ip-addr> 5) added a counter to

show the number of times each of these messages occur per tunnel. PR843172

• Service PICmay crash in CGNAT scenario when someone is retrying an initial SIP

*non-register* request at a fairly high rate while, keeping the same call-id for every














retry and changing the source port every time so we do not match any existing flow.

This should be a difficult race condition. PR844805

• Service PICmight crash in corner cases when EIM is enabled for SIP ALG.PR847124

• Whenallocate thememory fromsharedmemory forbitmapsused inportblocks, Junos

OS requests as many bytes as the size of the block. If customers assign like 10K block

size for deterministic nat or PBA, then Junos OS allocates 10K bytes for that bitmap.

However, it only needs 10K/8 bytes, as one byte can represent 8 ports. These huge

allocations are leading tomemory depletion whenmany source addresses are behind

the NAT, and port blocks are big. PR851724

• jnxNatSrcNumSessions SNMPOID is broken in 11.4R6-S1 release. PR851989

• In a CG-NAT scenario with Port Block/Bucket Allocation (PBA) configured, when the

port is exhausted due to receive ICMP or ICMPv6 echo requests fast with changing ID,

the services PIC will have nomore ports to allocate but create state objects for these

new packets, the state objects then can not be released any more, memory leak will

occur. If the service PIC usedmemory reaches 2GB then it will no longer allocate new

port blocks and some logs will be seen "port block memory allocation errors". The

memory usage of service PIC can be seen by following command: user@router> show

services nat pool detail Jan 10 11:52:37 Interface: sp-11/0/0, Service set: MOBILE-1 NAT

pool: POOL1-MOBILE, Translation type: dynamic Address range:

151.71.180.0-151.71.181.255 Port range: 512-65535, Ports in use: 48, Out of port errors:

196197999, Max ports used: 344898 AP-P out of port errors: 75964912 Max number

ofport blocksused: 55371, Currentnumberofport blocks inuse: 15, Port blockallocation

errors: 4098769297, Port blockmemory allocation errors: 196197999 Port blocks limit

exceeded errors: 75979500 PR854428

• Defining an application with destination-port range starting at 0 can cause TCP

handshake to fail through NAT. As a workaround, specify the application with

destination-port range starting at 1 instead of 0. PR854645

• Thenumberof termsperNAT rule cannot exceed200 for the inline-service si- interface.

This constraint check is not applicable for other type of service interfaces like sp-, AMS

andms- etc. Following errormessagewill be displayedwhen there aremore than 200

terms per NAT rule: regress@aria# commit [edit services] 'service-set ss8' NAT rule

rule_8 with more than 200 terms is disallowed for si-0/0/0.8 error: configuration

check-out failed. PR855683

• Due to a regression issue introduced in 11.4R8, "show services service-sets summary"

gives wrongmemory usage. PR857046

• Using "destination-address 0::0/0" in SFWv6 presents a commit warning.PR857106

• MS-DPCmay crash in certain scenarios when using CGNAT PBA and junos-rsh,

junos-rlogin, junos-rpc-services-udp and junos-rpc-services-tcp ALGs (either one) in

combination with EIM. PR862756

• WhenDHCPsubscribers log in and radius handsdown flow-tap variables the following

errors are seen in the log:"/kernel: rts_gencfg_dependency_ifstate(): dependency type

(2) is not supported." PR864444














• MIBmodule in file "mib-jnx-sp.txt" contains a coding error, which may lead to a loop.

PR866166

• TheRemoteCircuit IDDTCPtrigger (X-RM-Circuit-Id) isbeingenhanced tohavesupport

for embedded whitespace (\040). PR867937

• Any port or IP address value set in SIP VIA header for 'rport' and 'received' attributes

will not be checked or translated by the SIP ALG. There is usually no impact from this

to a voice call. The contact address inserted by the client in future requests will be the

external one but this will not disrupt the SIP ALG. Some rare clients howevermay have

someunexpected reaction that causesproblemsuchas trying to register 2 IPaddresses,

the internal oneand thepublic one, in the same registermessagewhich is unsupported

by the ALG and causes the message to be dropped. PR869725

• MX Series uses default receive window size of 128 in SCCRQmessage. PR870670

• Service PICmight crash in corner cases when SIP ALGmedia flows are deleted.

PR871638

• In Carrier Grade NAT scenario, MS-PICmight crash and generate a core file when Port

Block Allocation (PBA) block size is relatively big (8192 ports per block). This issue

usually happens when a new block needs to be allocated because the block currently

is exhausted. PR874500

• If RSP1 and RSP10 interfaces are configured on the same box issuing the "request

interface switchover rs1" or "request interface revert rsp1" causesbothRSP1 andRSP10

to switchover or revert. PR877569

• In a CGNAT environment when sp interfaces, which are underlying rsp interface, are

present in the configuration, sp interfaces service-options may wrongly overwrite rsp

interfaces service-options and syslog stopped working and inactivity-timeout values

were reset to the default values. PR881792

• AAPID list configuration not copied to Backup Routing Engine // 12.3R2.5. PR885833

• The jl2tpd process generates a core file as follows:

"./../src/bsd/lib/libc/stdlib/abort.c:69." PR887662

• The jpppd crash on LNS happened because the size of the udp based l2tp packet

exceeded the buffer length available. Themodificationwas done to discard the packet

instead of creating core. PR888691

• SIP ALG - Service PICmight crash when SIP flows are cleared. PR890193

• When the 'learn-sip-register' knob is enabled for the SIP ALG (it is by default), for a

SIP request in slow path implicitly denied by the firewall or NAT rules, a look up is done

to see if the SIP request has a target that corresponds to any current registration state,

in which case the corresponding reverse flows get created. While service PIC creating

the corresponding reverse flows, an internal error may occur, causing service PIC to

crash and generate a core file. PR899195

• In theSession InitiationProtocol(SIP)ApplicationLayerGateway(ALG)withportblock

allocation enabled scenario("user@root# set services nat pool <pool-name>

secured-port-block-allocation block-size <block-size>"), a SIP call to be set up and

the ports block are allocated for themedia flows.When the SIPmedia flows time out,
















the APPmapping starts using another port block. But if no enough port block to be

allocated, the services Physical Interface Card(PIC) might crash. PR915750

• In Carrier Grade NAT (CGNAT) environment, during heavy setup rate of CGNAT flows,

inter-chassis stateful High Availability (HA) sync flaps and then keepalive messages

are lost, as there is no control flow prioritization configured. HA sync connection keeps

disconnecting.After a longperiodof timePICsilently reboots. Followingsyslogmessage

might be seen when issue occurs: ROUTER-RE0 (FPC Slot 2, PIC Slot 0) PFEMAN:

Lost contact with master routing engine PFEMAN: Forwarding will cease in 4minutes,

59 seconds ROUTER-RE0 (FPC Slot 3, PIC Slot 1) PFEMAN: Lost contact with master

routing engine PFEMAN: Forwarding will cease in 4minutes, 59 seconds PR920723

• "replicate-services" configuration command-line interface(CLI) under "set serivces

service-set ..." is a hidden command, but it can be seen according to "root@user# run

show configuration services | display set" PR930521

• When tcp session is initiated from inside client and three way handshake is not

completed due to the fact that client did not ack the syn-ack send from the server,

service pic will send a tcp reset to the server after the timer expires. In this case tcp

reset is send on the wrong direction, instead sending on the outbound direction to the

server, servicepicwill send it in the inbounddirection.ThisPR fixes this issue.Noservice

impact is seen because of this. PR931433

• In the IPsec scenario, when all available SAs are expired and the sequence number is

wrapping for the IPsecpackets, thePhysical InterfaceCard(PIC)will delete theSecurity

Association(SA), however this is not reportedback to keymanagementprocess(kmd).

This would cause kmd and the PIC being out of sync regarding the known IPsec SAs,

then the traffic blackhole might occur. PR933026

• No SNMP trap generated when NAT or Flow sessions reach the threshold. PR933513

Software Installation and Upgrade

• 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 filesystem incorrectly. The affected platforms are

M/T/MX/TX/TXP/PTX. PR905214

Subscriber AccessManagement

• In DHCP/PPPoE subscriber management environment, after terminating subscribers,

authd process might crash and generate a core file due to an invalid pointer is used.

PR821639

• In situation when CoAmessage includes both LI attributes and CoA attributes authd

process fails to respond to CoA. PR821876

• WhenanMXSeries router is actingas theDynamicHostConfigurationProtocol (DHCP)

local server and interacting with Session and Resource Control (SRC) for subscriber

authorizationandprovisioning,SRCpassesback"framed-ip-address"duringsubscriber

login the local address pool. In this scenario, the OFFER and ACKmessages sent by

the MX Series router does not include dhcp-option 1, subnet-mask. PR851589













• Some requests internally sent to AUTHD process experience a timeout state which

may cause the subscribers to remain as either 'RELEASE' or 'TERMINATED'.PR853239

• When the router receives a CoA-Request message that includes the LI-Action VSA

[26-58] set to off or no-op, but is missing another VSA, such as Med-Ip-Address

[26-60] or Med-Port-Number [26-61], the router incorrectly returns a CoA-ACK

message to theRADIUSserver. Correctbehavior is to reject the requestwithaCoA-NAK

that includesError-Causecode402 to indicateanattribute ismissing fromthe request.

We recommend that all lawful intercept VSAs are sent in each CoA-Requestmessage.

PR867987

• The values of the attributes Acct-Delay-Time(41) in Acct-Stop retries #4, #5, #6, etc.

are NOT set correct. PR868645

• DTCP - First 127 triggers are applied. PR873013

• If the RADIUS Accounting Server is down, the RADIUS Attribute 49

(Acct-Terminate-Cause) ismissing in theAccountingSTOPmessages.Thiswill happen

after the first retransmit cycle. PR879368

• The authdlib logout/terminate release notify request might experience a processing

loop. PR888281

• DT-Need MIB revision for PR860298. PR891454

• PPPoE dual stack subscribers do not get activated services when firewall filters are

assigned. PR894860

• 'Client Session Activate request' was sent repeatedly once service activation failed for

'test aaa' command. PR897477

• The output of "test aaa" command does not return ADF (Ascend-Data-Filter) related

information. PR900050

• Request tostopserviceactivation inuseof "testaaappp"commandscenario.PR921459

• Test aaa ppp command not returning all VSA. Also some VSA values returned are

incorrect. PR921462

• VSA attributes are not displayed correctly in output of "test aaa ppp" cli command.

PR927054

• Whendestination-override is used(root@user#set systemtracingdestination-override

sysloghost<host-ip>), theuserAccess events arenot sent to theexternal syslog server.

PR931975

• 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

• The show ppp interface interface-name extensive and show interfaces pp0 commands

display different values for the LCP state of a tunneled subscriber on the LAC. The

show ppp interface interface-name extensive command displays STOPPEDwhereas

the show interfaces pp0 command displays OPENED (which reflects the LCP state




















before tunneling).Asaworkaround, use the showppp interface interface-nameextensive

command to determine the correct LCP state for the subscriber. [PR/888478]


• The logical router administrator canmodify and delete master administrator-only

configurations by performing local operations such as issuing the load override, load

replace, and load update commands. PR238991

• 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 IE7 browser, while deleting a user from the Configure > System Properties >

User Management > Users page on the J-Web interface, the system is not showing

warningmessage,whereas in theFirefoxbrowsererrormessagesareshown.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 the J-Web interface, Configure > Routing> OSPF> Add> Interface Tab is showing

only the following three interfaces by default: - pfh-0/0/0.16383 - lo0.0 - lo0.16385

To overcome this issue and to configure the desired interfaces to associated ospf

area-range, perform the followingoperationon theCLI: - set protocols ospf area 10.1.2.5

area-range 12.25.0.0/16 - set protocols ospf area 10.1.2.5 interface fe-0/3/1 PR814171

• On HTTPS service jweb is not launching the chassis viewer page at IE7. PR819717

• Onconfigure->clitools->point and click->system->advanced->deletion of saved core

context on "No" option is not happening at jweb. 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

• In this release Ngen-MVPN does not support NSR. But the commit check when

Ngen-MVPN and NSR is configured does not fail. In previous releases this commit

would fail. The commit check not failing for this configuration is planned to be fixed in

release 12.3 R4. In Release 12.3 R3 config with NSR and Ngen-MVPN configuration

should not be committed. Doing this commit can lead to routing application crashes

(like PR 864439) as it is an unsupported feature. PR827519

• In an FEC129 VPLS scenario, VPLS PseudoWire (PW) processing might hit an assert,

causing rpd process to crash with a core file generated. PR843482

• When theegressPEsareonaNGMVPN,which then leadson to theassert being silently

ignoredwhendual forwarders are setup over the PE-CE segment. Eventually duplicate

traffic being delivered by PE routers onto the ethernet where receiver is connected.

PR862586

• In BGP-signaled VPLSmultihoming scenario where best-site feature (available in

12.2+) is enabled, rpdmight crash when the site-identifier in configuration is replaced

by a new one. The core files could be seen by executing CLI command "show system

core-dumps". PR863023

• In a NG-MVPN scenario, on an ingress PE, if a RP is learned after receiving the BGP

Type-6 route from egress PE, the ingress PE doesn't create PIM (*,G) entries. This is

seenonlywithdynamically learnedRPs.With staticRPs, after a commit,MVPN flashes

the table and triggers creation of PIM (*,G) entries. PR866962

• Inaffected releases, theC-PIMAssertmechanism isnotworkingcorrectly inaMulticast

VPN environment. A typical scenario includes an access VLANwith four routers (CE1,

CE2, PE1 and PE2) which are C-PIM neighbors of each other. If CE1 sends a PIM Join to

PE1, and CE2 sends a C-PIM Join to PE2, both PEs start to inject the C-Multicast flow

in the access VLAN. This triggers the PIM Assert mechanism, which should result in

either PE1 or PE2 (one of them, not both), injecting the traffic, however the following

two situationsmay occur during oneminute ormore: - BothPE1 andPE2 keep injecting

traffic in the VLAN. - Both PE1 nor PE2 stop injecting traffic in the VLAN. Releases with

the fix work fine regarding the PIM Assert mechanism and do not show this abnormal

behavior. PR880575

• When a receiver already receiving multicast traffic for a group leaves the group, router

connected to the receiver sends aPrune upstreamand starts its upstreamPrune timer.

When the egress PE receives the Prune, it will withdraw Type-4 route. During this time,

if we 'clear pim join instance vrf' or (set routing-instances vrf protocols pim

disable/enable) is done on egress PE and when the Receiver joins the group again,

egress PE receives PIMGraftmessage but, drops it because it does not havematching

SG state. This resulting in egress PE not able to get trigger to send Type-4 and thereby

is not able to pull traffic from ingress. PR888901











• RPDmight experience software exception during clear pim join on routing-instance.

Typically seen in scenariowherePIM loadbalancing is implementedovereibgpsessions.

PR891586

• 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 thesecondvrf routewith the routeparametersof theprimary route.Sowhenchanges

the local preference of the vrf route might not work. PR935574



on page 3

•




on page 73





Resolved Issues in Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

The following are the issues that have been resolved in Junos OS Release 13.1 for Juniper

NetworksMSeries,MXSeries, andTSeriesRouters.The identifier following thedescription

is the tracking number in the Juniper Networks Problem Report (PR) tracking system.

• Current Release on page 73

• Previous Releases on page 86

Current Release

• Forwarding and Sampling

• General Routing

• High Availability (HA) and Resiliency

• Infrastructure

• Interfaces and Chassis

• J-Web

• Layer 2 Features

• Multiprotocol Label Switching (MPLS)

• NetworkManagement andMonitoring

• Platform and Infrastructure

• Routing Policy and Firewall Filters





• Routing Protocols

• Services Applications

• Software Installation and Upgrade

• Subscriber AccessManagement

• User Interface and Configuration

• VPNs


• When routerbootsupwithAmnesiacmode, (eg.with 'commit failed' due tostatements

constraint check failed), Address Resolution Protocol(ARP) Replies will be dropped

due to incorrect default arp policer on interface even after fixing the commit errors.

PR895315: This issue has been resolved.

General Routing

• Only 94 GRE(plain) sessions are in Established state after chassisd restart.PR801931:

This issue has been resolved.

• This is not an issue if duringPICor Interfaceoffline "WANQnumout-of-rangemessage

is seen with queue number larger than 512". This is transient condition and shall be

cleared by itself. This will not harm any traffic flowing through other interfaces or PIC.


• IPv6 address syntax on rpd log is violated of RFC 5952. For example,

2002:db8:0:0:1:0:0:1 must be logged as 2002:db8::1:0:0:1 in the logs, but it's logged

as 2002:db8:0:0:1::1. 2001:0:0:0:db8:0:0:1 must be logged as 2002::db8:0:0:1 in the

logs, but it's logged as 2001:0:0:0:db8::1. The fix is available in 11.4R10, 12.1R9, 12.2R7,

12.3R5, 13.1R4, 13.2R1, 13.3R1 and later release. PR840012: This issue has been resolved.

• FPC's in LCC are getting rebooted when CIP cable is pulled out ungracefully from SFC

CIP. PR865098: This issue has been resolved.

• If a router receives the BGP keepalive at time t, the next keepalive is expected at time

t+30 secs (+/- 20% jitter). However, right around the time when the next keepalive is

expected to be received, the BGP keepalive packet is dropped due to some network

issue (e.g. uplink towards peer flaps). During this scenario, retransmission of BGP

keepalive message on BGP peer would take long time and the BGP session will be

terminated due to hold timer expiry. PR865880: This issue has been resolved.

• In subscriber management environment with auto-sensed VLAN configured, in a rare

case, after some configuration changes made, kernel crash is observed leading to

Routing Engine reboot. The issue is identified as an interface which is not initialized

properly getting packets. PR878921: This issue has been resolved.

• RPDmight core dump if HFRR (Host Fast Reroute) is enabled on two logical interfaces

in the same routing instance for IPv6 and if link-local address is configured on those

logical interfaces. The core files could be seen by executing CLI command "show

system core-dumps". PR886424: This issue has been resolved.

• Whensyslog feature is configured in firewall filter, oneof the JunosOSmessagecreating

function has a bug,where thewhole string is copied directlywith no check for overflow.












This could easily overflow and results in no null-termination which causes memory

corruption and linecard crash. The core files could be seen by executing CLI command

"show system core-dumps". PR888116: This issue has been resolved.

• Traffic may be affected after performing an offline/online sequence on the PIC in a

T4000 system. This issue is usually seen when the event is performed on PICs carried

in a Type 5 FPC. PR892548: This issue has been resolved.

• When a BGP routes is resolved using a next-hop that is also learned in BGP (i.e. there

are multiple levels of next-hop resolution) and BGPmultipath is also used, during a

route churnnext-hop for suchaBGP route couldbe incorrectly programmed. This issue

is introduced in 12.1R1. PR893543: This issue has been resolved.

• Whenafilter/fwconfig ismodifiedpoisonednext-hops(logmessagePacketForwarding

Engine: Detected error nexthop) are reported and an automated jsim is performed on

the affected packets. This is happening on Packet Forwarding Engines with 2 jtree

segments and the issue is transitory. PR897107: This issue has been resolved.

• When GRES and ARP purging is enabled, frequent route flapping, route entry and

nexthop fail to syncupbetweenmaster JunosOSandbackupRoutingEngine. Sowhen

master Routing Enginewould like to addanewnexthopbut see backupREhas already

found a nexthop with same destination. It makes backup Routing Engine reboot and

crash on both Routing Engines. PR899468: This issue has been resolved.

• 100G Ethernet interface (Finisar FTLC1181RDNS-J3) on T4000 type-5 FPCmay flap

once after bringup . The solution is changing the register bandwidth. PR901348: This

issue has been resolved.

• "set system ddos-protection protocol sample aggregate bandwidth" command is not

taking effect. This can cause packet loss in ukernel for Routing Engine based sampling

if sampling rate exceeds 1000pps. PR905807: This issue has been resolved.

• bootp configuration on TXP platform referencing routing-instance fails to commit.


• Whenadding the"no-tunnel-services"knobunderVPLSprotocolsof routing-instances,

during the processing gap of the new knob, if routing protocol daemon (rpd) restarts

(i.e rpd crashes), logical interfaces with VPLS family do not show up, and there are no

logical interfaces available for the corresponding VPLS routing instances. Hence VPLS

connectionsmightbedown(stuck in LDstate)andcannotbe recoveredautomatically.


• High routing protocol process (rpd) CPU utilization is seen and it stays high (above

90%) until the rpd is restarted. PR925813: This issue has been resolved.

• For TXP-3D SIB 'XCHSL Link Error' alarm is generatedwhenHSL2 link faulty with CRC

errors. 'XCHSL Link Error' alarms are not cleared after optics disable & enable or cable

swap for a bad cable. The 'XC HSL Link Error' alarms are stale alarms after fixing the

faulty HSL2 link and CRC errors. PR926414: This issue has been resolved.

• SPMB on LCC node is crashing due to running out of memory after 38 days of uptime.

The voltagemonitoring in 10 seconds interval of the SIBs causedmemory depletion

and after 38 days uptime nomore memory is available.Once the SPMB comes back

up all fabric connectionwill get restarted andback operational after all re-initialization















is finished. During this restart time production traffic is affected. the following syslog

messages will get reported illustrating the IPC connection being dropped and

offline/online of the LCC SPMB chassisd[1579]:

CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for SPMB 0

chassisd[1579]: CHASSISD_SNMP_TRAP10: SNMP trap generated: Fru Offline

(jnxFruContentsIndex 14, jnxFruL1Index 11, jnxFruL2Index0, jnxFruL3Index0, jnxFruName

LCC4SPMB0, jnxFruType 10, jnxFruSlot 10, jnxFruOfflineReason2, jnxFruLastPowerOff

329953319, jnxFruLastPowerOn 1482) chassisd[1579]: CHASSISD_SNMP_TRAP10:

SNMP trap generated: FRU power on (jnxFruContentsIndex 14, jnxFruL1Index 11,

jnxFruL2Index0, jnxFruL3Index0, jnxFruNameLCC4SPMB0, jnxFruType 10, jnxFruSlot

10, jnxFruOfflineReason 2, jnxFruLastPowerOff 329953319, jnxFruLastPowerOn

329960352 The following command can be used to monitor the memory utilization

of the LCC SPMB Card. The output below utilization is reporting 99%

lab@sfc0-re0-router> show chassis spmb Oct 13 10:44:45 <..> lcc0-re0:

--------------------------------------------------------------------------Slot0 information:

State Online Total CPU Utilization 16% Interrupt CPU Utilization 0%Memory Heap

Utilization 99%<**** Buffer Utilization 22% Start time: 2013-09-05 05:09:29 UTC

Uptime: 38 days, 4 hours, 30minutes, 30 seconds Slot 1 information: State Online -

StandbyTotalCPUUtilization0%InterruptCPUUtilization0%MemoryHeapUtilization

0%Buffer Utilization 0%Start time: 2013-09-05 05:12:49 UTC Uptime: 38 days, 4

hours, 27 minutes, 10 seconds PR930259: This issue has been resolved.

• If IPv6 duplicate address is detected, interface can't recover to normal state after

flapping interface. Reconfigure IPv6 address will resolve this issue. PR936455: This


• Master Routing Engine reboot due to "panic: pfe_free_peer: not in peer proxy process

context" Trigger: replacement of backup RE. PR936978: This issue has been resolved.

• MP-BGProutewithdrawupdatemightnotbeensentafterdeletionofa routing-instance

configured with resolve import policy. PR942395: This issue has been resolved.

High Availability (HA) and Resiliency

• OnTXorTXPLineCardChassis (LCC)withGracefulRoutingEngineSwitchover (GRES)

disabled globally, if the following steps are done: 1) The em0 interface of a LCC's

Backup Routing Engine has failed (due to hardware failure or driver stops working) 2)

Amastership switchover is being requested from an LCC Routing Engine whose em0

interface isworking properly to the LCCRouting Enginewhose em0 interface has failed

3) Then GRES is re-enabled immediately after the switchover, with the newMaster

Routing Engine being the one where the em0 interface has failed This will cause all

FPCs on that LCC to disconnect from the old master Routing Engine, but cannot

reconnect to the newMaster Routing Engine (with the failed em0) either. PR799628:


• In certain systems configured with GRES, there is the possibility for the master and

backup Routing Engine to reach an inconsistent view of installed state. This fault may

be exposed if themaster Routing Engine experiences amastership watchdog timeout

at a time when it is not in sync with the backup Routing Engine for a particular piece

of state. In practice, this possibility exists only for a short time period after an Routing

Engine mastership change. Under such conditions, a replication failure may cause the










backup RE to panic. If the failure is seen, the backup Routing Engine will recover on

restart. In 11.4 and 12.1 releases without this fix, the fault may be experienced on any

GRES-enabled, non-multichassis configuration on a T Series router. For 12.2 and later

releases without this fix, the fault may be experienced on any GRES-enabled,

non-multichassis configuration on a T Series or MX Series router. PR910259: This issue

has been resolved.

Infrastructure

• Unsolicited Neighbor Advertisement is not sent from backup when vrrp switchover is

initiated. The fix is available in 12.3R4, 13.1R4, 13.2R1, 13.3R1 and later release.PR824465:


• Bug in internal Ethernet driver might lead into kernel data corruption PR876527: This


• Kernelmessages "SO_RTBL_INDEX"are seencontinuouslywhenLDPsession isdown.

The log messages were meant for debugging purposes. It is a harmless message. <

messages example > /kernel: setsocketopts: setting SO_RTBL_INDEX to 0 PR888162:


• Whenmulticast is running on amulti-chassis environment, during flapping of 224/4

or ff00/8 pointing tomResolve(NH), the LCCmastermight get replication error which

causing all FPCs going offline. This flapping of resolve route for multicast can occur

because of any of the following reasons: enabling or disabling multicast, deletion of

resolve route, or routing restart. PR897428: This issue has been resolved.

• A checksum error is seen on ICMP reply when the sequence, data field in the request

is set to zero. PR898487: This issue has been resolved.


• DuringFRRscenario,whenmultiple linksof anaggregatedethernetbundle fail resulting

in bundledownwhereminimum-links configuredasn-2, 'n' being total number of links,

and if the PLR is an MX960where links are hosted on 16X10GE card, there could be

significant losswhile pfe performs local repair. PR845520: This issue has been resolved.

• Because of the differences in VRRP checksum calculations, IPv6 VRRP configured on

routers that use JunosOSRelease 12.2 and later releases do not interoperatewith IPv6

VRRP configured in releases before Junos OS Release 12.2. PR874931: This issue has

been resolved.

• OndualRoutingEnginesplatforms, asaHighAvailability (HA)method,masterRouting

Engine should relinquishmastershipwhenbothRouting Engine-to-Packet Forwarding

Engine and Routing Engine-to-other-Routing Engine interfaces are down (this can be

achieved only when GRES is enabled). But now on dual Routing Engines platforms

except M10i and M20, master Routing Engine does not relinquish the mastership in

such conditions, even executing CLI "request chassis routing-engine master acquire"

on backup RE can not help. In such conditions, no FPC can be online without the

connection to master RE. With the fix, the backup RE will take up themastership

automatically if both the internal link interfaces are down. PR878227: This issue has

been resolved.


















• While a duplicate interface address (IFA) is configured for two interfaces, software

will accept that and pump up a error message like this:

%CONFLICT-4-DCD_PARSE_WARN_INCOMPATIBLE_CFG: [edit interfaces ge-0/0/0

unit 0 family inet address x.x.x.x/xx] : Incompatible configuration detected : identical

local address is foundondifferent interfacesButat kernel sidecannotacceptduplicate

IFA, and needs to delete the next-hop created for this operation. Due to code problem,

the clean up doesn't remove the duplicated IFA under heavy kernel workload. And it

will crash while trying to update this duplicated IFA to Packet Forwarding Engine side.


• RoutingEnginemight panic andgo todbpromptwhenamember link of anaggregated

Ethernet (AE) bundle is moved out of the bundle and the link is configured separately

in it in a single commit. PR892129: This issue has been resolved.

• Issue is because of vrrpd not configuring vrrp group id and state when its in transition

state. In normal scenario when vrrp moves to master it signals dcd to add the VIP.

When VIP gets added vrrpd gets a notification and updates state and group id

corresponding to that VIP. While updating state vrrpd checks the current state, if state

if master it updates state asmaster and if its backup it updates it as backup. But if vrrp

state is in transition it does not do anything. In this scenario vrrp sessions on Xardas

were firstmoving to backup. This results in addition of VIP. But before ifa addmessage

is received some of the vrrp sessionsmoves to transition state.When ifamessages for

those sessions are received, no update happens for them as they are neither inmaster

or backup state. PR908795: This issue has been resolved.

• When an interface is configured with VRRP protocol, IP address associated with this

interface might disappear after deactivating then activating the interface. When this

issue happens, KRTmaybe getting stuck and never clean up. If the interface belongs

to a routing-instance, then deactivate/activate the routing-instance can also trigger

the same issue. Issue command 'show krt queue' to verify: root@ABC-re0> show krt

queue Routing table add queue: 1 queued ADD table index 37, gf 1 (1377) error 'File

exists' The issue is introduced in 12.2R5 12.3R3 12.3R4 13.1R3 13.1R4 13.2R1 PR912295:


• For IQ2 PIC, when the setting shaping rate is too high, when configured it with "set

chassis fpc 0 pic 1 traffic-manager logical-interface-base-shaping-rate 16" and this

will reset the shaping rate to 1Gbps. The correspondingmessages are logged in debug

level. In the fix, it is corrected into info level. PR920690: This issue has been resolved.

• PCS statistics counter(Bit errors/Errored blocks) not working on Mammoth PIC(xge).











J-Web

• A vulnerability in J-Webmay allow remote attackers to bypass CSRF (Cross-Site

Request Forgery) Protection in J-Web. This allows performing administrative actions

such as creating new administrative accounts as ameans to gain complete control

over the device. This issue was found during internal product security testing. Please

refer to JSA10597 for additional information. PR827189: This issue has been resolved.

Layer 2 Features

• While executing command "clear vpls statistics instance all", "all" is not considered

as an instance name and then the NULL variable in instance name field causes the

routing protocol daemon (rpd) crashes. The core files could be seen by executing CLI

command "show system core-dumps". PR901197: This issue has been resolved.

• "show snmpmib walk ascii jnxVpnIfStatus" doesn't work for BGP VPLS when there is

incompleted BGP VPLS instance configuration or LDP VPLS instance. PR918174: This



• LSPmetric will be not correctly changed as the new configured one after committed

when cspf finds an Explicit Route Object (ERO) different from the current ERO and

the Path State Block (PSB) re-signaling fails. This is because a change in metric is a

local PSB change, but after a configuration change (for example, the bandwidth

requirement was changed), PSB and associated routes used to get this change only

after a cspf computation followedbya session refreshor re-signaling. If the re-signaling

fails, the configuredmetric value is not updated in theexistingPSBand the routemetric.


• This message was used to recorded error condition from nexthop installer. Over time,

it becomes common function and samemessage will be printed in many valid

conditions, leading toconfusionon thesemessage-logs.PR895854:This issuehasbeen

resolved.

• When a configuration change is made to label-switched path's (LSP) preference, it

results in LSP restart which is not acceptable as it results in traffic loss. This PR will

make sure the change in LSP's preference is handled in make-before-break fashion.


• IPv6 traceroutemaynot showsomehops for scenarioswhere 1)TwoLSPsare involved.

2) INET6 Shortcuts are enabled. In such scenarios, hops that are egress for one LSP

and ingress for the next LSP in the traceroute do not show up. This was a software

issuewith icmperror handling for packetswith ipv6payloadhavinga ttl of 1.PR899283:


• With Junos OS Release 12.1R1 or later, any configuration changes in the MPLS stanza,

P2MP LSP connection with a single branch, will flap and cause brief traffic drops if

allow-fragmentation knob is configured under the MPLS path-mtu stanza. No traffic

drop are seen if the P2MP LSP has two or more branches. Any application which is

using P2MP RSVP LSP is exposed to this issue, like ccc p2mp-transmit-switch, static

route with p2mp-lsp-next-hop etc. PR905483: This issue has been resolved.














• If the maximum-ecmp next-hops under [edit chassis] hierarchy is configured as 32 or

64 (more than the default value of 16), the routing protocol daemon (rpd)might crash

on newmaster Routing Engine after performing graceful Routing Engine switchover

(GRES). The root cause here is while merging nexthops, the Junos OS is iterating over

only 16 gateways instead of configuredmaximum-ecmp number and finally results in

an assert. The core files could be seen by executing CLI command "show system

core-dumps". PR906653: This issue has been resolved.

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


• In certain circumstance, the Junos OS rpd route flash job and LDP connection job are

always running starving otherwork such as stale route deletion. These jobs are 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 for which it has a ingress tunnel (the same prefix is also learnt via IGP) creating

a circular dependency as BGP routes can themselves be resolved over a LDP route.


• In a highly scaled configuration the reroute of transit RSVP LSPs can result in BGP flap

due to lack of keepalivemessages being generated by the Routing Engine. PR946030:


Network Management andMonitoring

• When we do SNMP polling via CLI on a big MIB node which has lots of OIDs and huge

data, like "show snmpmib walk 1.3.6.1.4.1". CLI might not be able to consume data at

the rate it was being generated by snmpd, so the snmpd buffer is occupiedmore and

more, eventually this would cause snmpd to reach its limit then crash. PR864704: This


• When you perform the belowMIBWalk on interfaces, for some interfaces the

ifLastChange valuewill showavalueof zero. showsnmpmibget ifLastChange.<SNMP

ifIndex>will show a value of zero. ifLastChange.<SNMP ifIndex> = 0 PR886624: This


• Amemory leak in the cosd process is seen when both of the following conditions are

met: - multiple OIDs from jnxCos MIB, that are under the same logical interface

hierarchy, are queried in a single SNMP query sent to the device (i.e. in a single PDU) -

either "per-unit-scheduler" or "hierarchical-scheduler" configured on the physical

interface The followingmessages will be loggedwhen the cosd process exceeds 85%

of its maximum usable memory: router-re0 /kernel: %KERN-5: Process (1457,cosd)












has exceeded 85% of RLIMIT_DATA: used 1894060 KBMax 2097152 KB PR893464:


• In an IS-IS scenario, with trace option enabled and the system log level set to debug

routing options, if the router has two IS-IS neighbors with the same router ID, after you

configure the same ISO system ID on these two IS-IS neighbors, RPD on the router

crashes and generates core files. PR912812: This issue has been resolved.


• XML tags for get-software-information output missing some elements of new Junos

OS service release naming convention. PR783653: This issue has been resolved.

• In CGNAT environment, Source-Address only hashmight be getting broken on MPC

after Service PIC restart.PR827587: This issue has been resolved.

• PPE traps are seen when an interface on a MPC is added to an Aggregated Ethernet

(AE) bundle configured with LACP. During this operation before the bundle becomes

active, its channel table (which is usedwithin packet forwarding process on Line Card)

mighthavestaleNHs(Next-hops) forabrief time-whichcauses these traps.PR828293:


• With an interface-specific filter contains a percentage policer configured on several

interfaces, when the shaping rate of an interface changed, the percentage policer

instances of the filter applied on that interface need to be updated. If FPC restarts

when policer instances are being updated, an interface-specific filter instancemight

not be instantiated in hardware, causing FPC to dereference a NULL pointer, then FPC

crashes with core files dumped. PR874923: This issue has been resolved.

• For MX Series based FPC only, on PHP->PE link performing mpls tunnel label pop

operation, customMPLSMTU allows 4Byte more than configured MPLSMTU size.


• In L2VPN scenario, on the PE router, if the encapsulation of the PE-CE interface is

vlan-ccc and there is a COS filter under the interface, when the interface flaps, it can

cause all the traffic to different sites via different outgoing interfaces is forwarded

incorrectly through one of the interfaces. Meantime, whenmanually flap the

label-switched paths (LSPs) on the router after the problem occurred, the traffic is

forwarded incorrectly still but only the egress interface will change to other one. The

way to resolve the problem ismanually clearing the LSPs on the PE router. PR887838:


• High rate of traffic to the Routing Engine may cause control traffic stoppage to the

Routing Engine. The indication is the following type ofmessages: "WEDGEDETECTED

IN Packet Forwarding Engine ... TOE host packet transfer: reason code 0x1 PR896592:


• If there are private sessions in place, it should not abort the effective/revoke of

conditional groups. In affected releases, it is notworking.PR901976: This issuehasbeen

resolved.

• Command "show ddos-protection protocols" doesn't report correct Arrival and Max

arrival pps rates.Onebit of rate value atPacket Forwarding Engine iswrongly setwhich

results in a wrong ddos rate value. PR908803: This issue has been resolved.



















• TheDDOSclassification forDynamicHostConfigurationProtocol (DHCP) "leasequery"

message is notworking. Thismessage is treatedas "unclassified".PR910976:This issue

has been resolved.

• A certain set of Junos OS CLI commands and arguments allow root access to the

operating system. This allows any user with permissions to run these CLI commands

and achieve elevated privileges and gain complete control of the device. PR912707:

This issue has been resolved. and

• 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: This issue has been resolved.

• With xml:warning and xml:error enabled inside commit scripts, when there is an XML

tagmismatch detected in any of the commit scripts, the following errors are seen:

error: [filename: xnm:rpc results] [line: 771] [column: 7] [input: routing-engine]Opening

and ending tagmismatch: routing-engine line 7 and rpc-reply error: [filename: xnm:rpc

results] [line: 773] [column: 6] [input: rpc-reply] Opening and ending tagmismatch:

rpc-reply line 6 and junoscript error: [filename: xnm:rpc results] [line: 774] [column:

2] [input: junoscript]Premature endofdata in tag junoscript line 2PR922915:This issue

has been resolved.

• When xnm-ssl or xnm-clear-text is enabledwithin the [edit system services] hierarchy

level of the Junos OS configuration, an unauthenticated, remote user could exploit the

XNM command processor to consume excessive amounts of memory. This, in turn,

could lead to system instability or other performance issues. PR925478: This issue has

been resolved.

• DDOS_PROTOCOL_VIOLATION alarm shows incorrect timestamps

<time-first-detected> and<time-last-detected> onmessages. Both fields indicate the

same timestamps. Timestamps <time-first-detected> and <time-last-detected> are

overwritten. The fix is available in 12.3R5, 13.1R4, 13.2R3, 13.3R1 and later release.


Routing Policy and Firewall Filters

• Astack consumption vulnerability in the regcomp implementation in theGNUCLibrary

allows an attacker to cause a denial of service (resource exhaustion) via a regular

expression containing adjacent repetition operators or adjacent bounded repetitions.

Junos OS uses regular expressions in several places within the CLI. Exploitation of this

vulnerability can cause the Routing Engine to crash and rpd application leading to a

partial denial of service. Repeated exploitation can result in an extendedpartial outage

of services provided by rpd. Please refer to JSA10612 for additional information.


• Junos OS releases with a fix for PR/706064 have a regression where the vrf-import

policy sanitation logic is faulty. A "# commit check" will fail when the first term

referencesa 'target' community and the second term referencesan 'origin' community.

This should pass the check. PR911350: This issue has been resolved.















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 nexthop, which is not

pushed to the Packet Forwarding Engine. When a non-fxp0 interface is active later,

the private nexthopwill be sharedby the non-fxp0 interface aswell, resulting in packet

drops destined to ff02::2 on the non-management interface. PR824998: This issue has

been resolved.

• Junos OS label block allocation can only return block size as power of 2 (e.g. 2, 4, 8,

16,...). In inter-as option-b L2VPN scenario, routing protocol daemon (rpd) core is seen

when theASBR receives a non-power-of-2 label block size fromother vendor's device.

The root causehere iswhen rpd requests thenon-power-of-2 label block size, anassert

occurred. The core files could be seen by executing CLI command "show system


• When configuring CAC for a physical interface, the softwaremight enable CAC for unit

0on that interface, butmight notbeable todelete itwhen theconfiguration is removed.


• OnT640/T1600 routerswith Enhanced Scaled (ES) FPCs equipped and all MXSeries

routers with MPC, the Bidirectional Forwarding Detection (BFD) sessions over

Aggregated Ethernet (AE) interfaces might be down after performing In-Service

Software Upgrade (ISSU). Note, the problem is only seen on FPC ( Packet Forwarding

Engine) based BFD (contrasts with RE based BFD) and the problem ismostly seen on

T640/T1600 routers even thought the problem affects MX Series routers in principle.


• In PIM scenario with trace options enabled, routing protocol process (rpd) crashwhen

PIM interface is NULL andPIM trace options are configured. And below logwill be seen

on console and in message log: /kernel: BAD_PAGE_FAULT: pid 2225 (rpd), uid 0: pc

0x8653c0a got a read fault at 0x3e0, x86 fault flags = 0x4 PR886038: This issue has

been resolved.

• Global IS-IS will not see LDP sync notification during link down/up flap when other

no-forwarding routing-instance IS-IS interface not enable ldp-synchronization.


• In PIM SSM scenario, the multicast forwarding state might get stuck in "pruned" state

after restarting rpd process on first-hop-router (FHR). PR892171: This issue has been

resolved.

• BGP "accepted-prefix-limit" feature might not work as intended when it is configured

together with "damping". Root cause of this issue is that when BGPmodule count the

maximum routes accepted from BGP neighbor, it doesn't count the accepted BGP

routes which in damping status. So when these damping routes are reused, the total

numberof receivedBGProutesexceeds theconfiguredvalue for "accepted-prefix-limit"

. PR897124: This issue has been resolved.

• In PIM densemode, if the Assert loser router receive a join/prune (S,G) message with

upstream neighbor is the loser router, it should send a Assert(S,G) on the receiving

interface to initiate a new Assert negotiation to correct the downstream router's RPF














neighbor, but our device will not. This PR has solved the issue. PR898158: This issue

has been resolved.

• Improvements were made in the area of importing routes in vrf routing-instances (in

scaled configuration). As a results of these improvements there is a possibility to have

a rpdcrashandotherdifferent issueswhen these improvementsareused inconjunction

with GRES/NSR. There is no workaround. PR900733: This issue has been resolved.

• In multicast scenario with PIM enabled, when you configure both static RPmapping

with override knob and dynamic RPmapping (such as auto-RP) in a single routing

instance, allow the static mapping to take precedence for a given group range, and

allow dynamic RPmapping for all other groups, but a software defect cause that RP

is selectedbasedondynamicRPmappingaddress, insteadofaccounting for this static

override knob. PR912920: This issue has been resolved.

• DR sends a delayed ACK to the LSA on the interface on which the LSA is flooded. This

leads to BDR sending only directed ACK to DR, DR-Other is therefore not receiving this

ACKand ishence retransmitting theLSA toBDR.PR914803:This issuehasbeen resolved.

• Under specific time-sensitive circumstances, if BGP determines that an update is too

big to be sent to a peer, and immediately attempts to send a withdrawmessage, the

RPDmight crash. An example of an oversized BGP update is one where a very long

AS_PATHwould cause the packet to exceed themaximum BGPmessage size (4096

bytes). Theuseof a very largenumber ofBGPCommunities canalsobeused to exceed

themaximum BGPmessage size. PR918734: This issue has been resolved.

• Whennonstop active routing (NSR) is configured andpath-selection is changed, there

might be a non-functional impacting rpd core during the commit process. PR928753:


• In L2VPNscenario, after deactivateand thenactivate "setprotocolsbgppath-selection

l2vpn-use-bgp-rules", the following error messagemight be seen: moat rpd[1586]:

bgp_l2vpn_sig_get_prefix, received invalid label block (base=0, range=0) for L2VPN

prefix 13979:30726:2:1/96moat rpd[1586]: bgp_l2vpn_sig_get_prefix, received invalid

label block (base=0, range=0) for L2VPN prefix 13979:75526:2:1/96. PR929107: This


• "show route advertising-protocol bgp <nbr> table foo.mvpn.0" stops working after

PR-908199 fix PR929626: This issue has been resolved.

• On the first hop router if the traffic is received from a remote source and the

accept-remote-source knob is configured, the RPF info for the remote source is not

created. PR932405: This issue has been resolved.

• If you have fix for PR-929626, Avoid the following show command in a VPN setup

"show route advertising-protocol bgp <nbr_addr> table foo.inet.0"Where <nbr_addr>

is peer within routing-instance "foo" PR936434: This issue has been resolved.

• In MVPN scenario, while performing CLI command "show route advertising-protocol

bgp <neighbor>", the rpdmight crash due to a timing issue that BGP rib for

bgp.mvpn-inet6.0 table is NULL. PR940491: This issue has been resolved.


















• In a L2TP scenario, after performing an SNMPwalk of "jnxL2tpTunnel" or

"jnxL2tpSession" MIBs, the SNMP reply message fails to be written because write

buffer is exceeding MTU, causing Routing Engine CPU spikes to 100%. PR905218: This


Software Installation and Upgrade

• In this case, since the high level package (i.e. jinstall) is signed, the underlying

component packages are not required to be signed explicitly. However the infra was

written suchaway todisplaywarningmessage if the component package is not signed

(i.e. jpfe). PR932974: This issue has been resolved.

Subscriber Access Management

• Due to some timing issues,MXSeries routerwas generatingwrongLLPDF logs "LLPDF:

llpdf_client_connection: Unknown session" every 10 seconds. This misbehavior has

been fixed by the changes on this PR. PR894013

• If the PPP session is dropped, before NCP transitions to OPEN state, MX BNG sends

RADIUS Acct-Stop, but with these missing attributes: Acct-Input-Octets(42),

Acct-Output-Packets(43), Acct-Input-Packets(47) and Acct-Output-Packets(48).

This has been fixed by this PR. All 4 attributes will be listed, with the null value.

PR896535

• If there is secureId configuration present on the chassis, when the validate phase of

"request system software add" runs, the netstat might crash due to system cannot

load the SecureIDmodule during syntax checking. The generation of the core has no

effect on the verification results, anddoesnotadversely affect theupgrade/downgrade

operation. PR911232: This issue has been resolved.


• Inanaggressiveprovisioningscenariousingscriptsorautomated tools,we recommend

that you do not use rollback immediately after a successful commit. PR874677: This


• If a configuration filewhichcontainsgroups relatedconfiguration is loadedbycommand

"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: This issue has been resolved.

VPNs

• In L2circuit scenario, after L2circuit established, if Pseudowire flaps (e.g. interface

flapping), while routing protocol daemon (rpd) processing this change, memory

corruptionmightoccur, causing rpdprocess tocrashwith core filesdumped.PR900257:


• This PR enables default advertisement of MVPN from themain BGP routing tables

bgp.mvpn.0 and bgp.mvpn-inet6.0 instead of VRF routing table foo.mvpn.0 or

foo.mvpn-inet6.0. It also removes withdraw suppression for extranets. If extranets are














used,advertise-from-main-vpn-table isenabledbydefault foraMVPNNLRI.PR908199:


• In Rosen and NG-MVPN running in rpt-spt mode, valid (*,G) forwarding state can be

created (it can not be created in spt-only mode). If there is rpf-check-policy added to

MVPN instance and the rpd check is associated on the (*,g) forwarding route

installation, the rpdmight crash. PR915672: This issue has been resolved.

• 'show route table VRF.mvpn.0 extensive|detail' for mvpn VRF routing tables will not

showBGPTSI info (whichpreviously contained theMVPNPMSI attribute) for outgoing

MVPN route advertisements. Since PR 908199, TSI info for these routes is shown on

the copy of the route advertised from themain bgp.mvpn.0 table. 'show route table

VRF.mvpn.0 extensive|detail' now shows the MVPN PMSI attribute in the main body

of the route output. PR939684: This issue has been resolved.

Previous Releases

• Resolved Issues in 13.1R3 on page 86

• Resolved Issues in 13.1R2 on page 93

Resolved Issues in 13.1R3


• During addition/deletion or just deletion of interfaces with configuration for shared

scheduler, some portion of memory is not reclaimed back normally. So continuous

addition/deletion of these interfaces results in memory depletion, packet loss and

other issues. PR890986: This issue has been resolved.


• In T4000 platforms with ES-FPC, for IPv6 firewall filters with match conditions on

addressprefixes longer than64bits, in somecorner cases, the filtermaynotbecorrectly

evaluated and packet loss may occur. PR879829: This issue has been resolved.

• host@user>showservicesaccounting flow-detail destination-prefix 20.1.1.2/32Service

Accounting interface: sp-2/0/0, Local interface index: 147 Service name: (default

sampling) Interfacestate:AccountingProtocol InputSourceSourceOutputDestination

Destination Packet Byte Time since last Packet count for Byte count for interface

address port interface address port count count active timeout last active timeout last

active timeoutudp(17)xe-0/0/3.0 10.1.1.2whois++(63)xe-0/0/2.020.1.1.2whois++(63)

1075917 4949218200:17:55 178092281922412 tcp(6) xe-0/0/3.0 10.1.1.2 0 xe-0/0/2.0

20.1.1.20 106479489803400:01:46 183507084413220PR881629:This issuehasbeen

resolved.

• In scaledMPLS scenario, when LSP path switchover happens, sample process deletes

samplingparameters fromthePacket ForwardingEngineandasa result of thatPacket

Forwarding Engine stops exporting flows to the collector. PR891899: This issue has

been resolved.













General Routing

• If per-packet load balancing is enabled and there are multiple Equal-Cost Multi Paths

(ECMP) to the same destination, after topology changes and performing a couple of

NonStop Routing (NSR) switchovers, Kernel Routing Table (KRT) queuemight get

stuck permanently with the following message logged: rpd[1475]: %DAEMON-3:

Cannot perform nh operation DELETE nhop (null) type unicast index 1114846 errno 1

user@router> show krt queue Routing table add queue: 0 queued Interface

add/delete/change queue: 0 queued High-priority multicast add/change: 0 queued

Indirect next hop add/change: 0 queuedMPLS add queue: 0 queued Indirect next hop

delete: 1 queued DELETE index 1114846 (16275) error 'EPERM -- Jtreewalk in progress'


• It is possible for RPD corewhen the following conditions aremet: - VRFwithmultipath

knobconfigured - static routeswithnext-hopswhichare indirect typeandneeds further

resolution - the numerically lowest (smallest IP) next-hop of indirect type becomes

unreachable RPD core is NOT triggered in either of the following scenarios: - no

multipath under VRF - if there is no static route entry - static route whose next-hops

are indirect type requiring further resolutionmultipath under VRF is supported only for

BGP configurations. multipath in other conditions are not supported, and a bug in this

detection phase is fixed in this PR. PR847214: This issue has been resolved.

• Output of "show subscribers physical-interface aex" displays multiple AE links.


• FPC's in LCC are getting rebooted when CIP cable is pulled out ungracefully from SFC

CIP. PR865098: This issue has been resolved.

• Addinga routing-instancewith "/" in its namewill cause the router not toboot properly

if logical-systems were previously configured. PR871392: This issue has been resolved.

• On systems containing XM-based linecards(for example, MPC3, type 5 FPCs), if a

member link of an aggregate ethernet (AE) bundle is repeatedly flapped, the flapped

member linkmaystop transmitting traffic. Traffic isn't gettingdropped, as the remaining

member-links will pick up the slack. But in some cases (the traffic is large or some

members encounter the problem together), traffic loss will happen. PR875502: This


• The Routing Engine might become non-responsible due to the exhaustion of kernel

mbufswith followingmessages. /kernel:Mbuf:HighUtililizationLevel: (Low)Throttling

low priority requests (10ms) /kernel: Mbuf: High Utililization Level: (Medium) Throttle

low priority requests (150ms) /kernel: Mbuf: High Utililization Level: (High) Block low

priority requests. PR886083: This issue has been resolved.

Infrastructure

• Kernel fails to generate ICMP ttl expired when IP packet len is a multiple of 256.


• Aggregate Bundle interface with IPV6 Interface stuck in Tentative state. Trigger was

deactivation/activation of ae-interface. PR844177: This issue has been resolved.

• With nonstop active routing (NSR) enabled, while performing the graceful Routing

Engine switchover (GRES), Junos OS fails to restore BGP peers' TCP connections on













the newmaster Routing Engine's replicated socket due to it is not able to find the BGP

peer address's route, causing BGP peers to flap with following logs: /kernel:

jsr_sdrl_merge: PSRMmerge failed 65 rpd[xx]:

RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer a.b.c.d (Internal AS X) changed

state from Established to Idle (event TcpSocketReplicationError). PR862796: This


• After enabling firewall filter of IPv6 on Aggregated Ethernet (AE) interface to block

Micro BFD Packets (Dst Port 6784), kernel crashes continually onmaster and backup

Routing Engine due to double free of memory. PR864112: This issue has been resolved.

• IPv6Neighbor discovery(ND) failed aftermultiple GRES. Nexthop getting stuck in hold

state forever. We also see that the neighbor state is in NO_STATE and it is on ND timer

queue. In this condition, on ND timer expiry it never sends neighbor solicitation (NS)

out and it never transitions to known ND states. Use "show route forwarding-table"

CLI command to see the result of IPv6 route in hold state. root@ABC> show route

forwarding-table Destination Type RtRef Next hop Type Index NhRef Netif 1234::56

/128 dest 0 1234::56 hold 1902 1 irb.5678 Use "show ipv6 neighbors" CLI command to

see the result of IPv6 ND state in NO_STATE. root@ABC> show ipv6 neighbors IPv6

Address Linklayer Address State Exp Rtr Secure Interface 1234::56 none nostate 0 no

no irb.5678 PR864133: This issue has been resolved.

• Kernel may crash when delete routing instance under the donor and unnumbered

address borrower scenario. When the deleting for the donor is before the deleting of

the corresponding unnumbered borrower, in this window, the donor interface does not

have an address, arp processing over the borrower interface during this windowmay

trigger thecrash. Thecore files couldbeseenbyexecutingCLI command"showsystem



• IQ2 core is seen after ISSU and traffic will be lost for a while(about 40s). The crash

happens during processing of scheduler free message which comes just after ISSU

complete on IQ2. Then the heap structure is invalid causing panic. The fix is moving

the process to ISSU sync stage. PR845257: This issue has been resolved.

• The backup Routing Engine may log the following often in chassisd: Feb 17 12:40:01

CB:1 need not to sync information Feb 17 12:40:21 CB:1 need not to sync information

Feb 17 12:40:41 CB:1 need not to sync information Feb 17 12:41:01 CB:1 need not to sync

information This is a harmless message that can be ignored. PR857698: This issue has

been resolved.

• Not able to ping with do-not-fragment bit with packet size of 1400, after deleting the

mtu constraint between logical-systems. PR869515: This issue has been resolved.

• Injecting Enhanced RDI-P(G1 bit5-7:0x2 Payload defect) alarm to a MPC 10GbE

WAN-PHY interface causes RDI_P and LCD-PAIS-V alarm onmessages. This is due to

string typo. RDI_P and LCD-P should be printed onmessages. PR872133: This issue has

been resolved.














• Both VRRP routers keep backup-backup state until "startup-silent-period" expires if

both "startup-silent-period" and "delegate-processing" are configured. PR873488:


• Issue will be hit when amember link of an AE bundle is moved out of the AE and the

logical interfaces are configured separately in it in a single commit. Ex: If the below

configuration is committed inasingle commit this issue is seen. [edit interfacesxe-7/1/1]

+ vlan-tagging; - gigether-options { - 802.3ad ae0; - } [edit interfaces xe-7/1/1] + unit

0 { + vlan-id 1; + family inet { + address 101.101.101.254/24; + } + } PR892129: This issue

has been resolved.

Layer 2 Features

• When VPLS is configured with GRES, the backup Routing Engine responds to certain

route replication requests by simulating address learning. If the route being replicated

is associatedwith anLSI orVT interface, theaddress learning code referencesa special

LSI or VT nexthop. Thus, there is a dependency between that route and that nexthop.

This fix is to explicitly enforce this ifstatedependency, ensuring that the special nexthop

is seen by the peer before the route. PR867929: This issue has been resolved.

• For a configurationwith bridge domains containing aggregate interfaces, trafficwhose

destination address is broadcast, multicast, or unknown will not be load-balanced

across the member links of such interfaces. Instead, all such traffic will be sent out a

single link of the aggregate interface. With this PR change, load-balancing will always

be applied to such configurations for traffic whose destination address is broadcast,

multicast, or unknown. This change restores the functionality of older releases.











• New knob is provided to set the prefix to compare requested ip and server address.

Knob is configured as - [edit system services dhcp-local-server] #set

requested-ip-network-match <0-31> For V6 [edit system services dhcp-local-server]

#set dhcpv6 requested-ip-network-match <0-127> Default will be 8 for v4 and 16 for

v6 (first terms). PR872145: This issue has been resolved.

Multicast

• On TXP systemwith multicast enabled, it is advised not to deploy this release on the

system.Whenmulticast is running on amulti-chassis environment, during flapping of

224/4 or ff/8 pointing to mResolve(NH), wemight get replication error on the LCC

master causing all FPCs going offline. This flapping of resolve route for multicast can

occur because of any of the following reasons: enabling or disabling multicast, hitting

multicast table limit and deletion of resolve route, or routing restart. PR897428: This



• Thecleanupproceduresmay leave transient inconsistent referenceswhen the interface

address of an MPLS enabled GRE or IPIP tunnel is being deleted or the action taken

implies an internal reconfigurationof the interfaceaddress (for exampleMTUchange).

During theseperiods, if these referencesarebeing reusedbyaparticular task, the kernel

may report an invalid memory access and restart. PR844790: This issue has been

resolved.

• The routing protocol daemon (rpd) might leak memory when there are MPLS LSP

changes, the memory leak could eventually cause rpd process to crash. PR847354:


• The LDP protocol might use the lowest IP address configured on an interface even if

there is another (higher) address that is explicitly configured as primary. This can lead

tounexpectedLDPsession flap if the lowestbutnon-primaryaddress isbeing removed

from the configuration. PR858838: This issue has been resolved.

• Apply group with session parameters will not work for LDP protocol from 12.2 release

onwards without the fix for this PR. This is due to re-organization of 'ldp session'

configuration during 12.2 development. PR868945: This issue has been resolved.

• The VpnId value contains no information, but was being returned as the empty string,

when the MIB requires that it be a length 7 octet string. The value (since it contains no

information is now returned as 7 zeros). PR882828: This issue has been resolved.

• When a LDP egress router advertises multiple prefixes, by default the prefixes are

bound to a single label and aggregated into a single forwarding equivalence class

(FEC). If the nexthops of someprefixes in the FECchange (e.g. LDP interface flapping),

LDP still try to bind a single label to all of the prefixes which is incorrect. PR889585:

















• When snmp unknown PDUs are received, the appropriate counter in (show snmp

statistics) is not incremented. PR865121: This issue has been resolved.

• Polling an snmp oid that was excluded from the snmp view in configuration might

trigger an increase in CPU load related to SNMP and RPD demons. PR866541: This



• RMOPD crash is due to sort of buffer overflow crash and library function being used

improperly. It is not caused by RPM scaling, This issue happens randomly and hard to

point out the specific trigger. PR277900: This issue has been resolved.

• On Junos OS 10.4R8 or higher on MX Series platforms, L3VPN application using

l3vpn-composite-nexthop when the indirect-next-hop configuration statement is

added or removedmight cause traffic traffic drops affecting L3VPN flows. To recover

from this condition all the l3vpn prefixes need to get removed and installed new into

the forwarding-table, like clearing the bgp peers where the routes are learned from.


• In rare case, after no graceful FPC rebooting (i.e. temporary power failure on egress

FPC), fabric ASIC on ingress STFPC can run into temporary problematic status. This

will cause temporally large delay on fabric traffic from STFPC to the egress FPC.


• FPC core file with the feature copy-plp-all enabled when add link to existing AE

interface, which is part of downstream interface list of a multicast route. PR842046:


• In the T4000 Type 5 FPC platform, aperture management can lead to a collision

between the sched tick timer and asic driver interrupt handlers, whichwill result in FPC

crashes. PR857167: This issue has been resolved.

• mgd crashed with core-dump after executing "show configiration | display rfc5952".


• After restart of a FPC, when it comes online the queue block on another FPC becomes

locked up and all traffic into the fabric from this Packet Forwarding Engine is dropped

The issue occurs when there is a lot of high-priority traffic and low priority traffic get

stuck behind and therefore causes the time out and queue draining. PR877123: This


• This is a regression issue introduced by the fix of PR801982, which causes DOMMIB

values for SFP+ "rx power" related statistics are incorrect. Please note that XFP is not

affected. PR878843: This issue has been resolved.

• When we are deleting a configuration hierarchy which has no groups applied, the

corresponding group object hierarchy is alsomarked as changed in commit script view.


• Deactive/deleteAE interfacewhen route is flappingmight cause thePacket Forwarding

Engine to crash. PR884837: This issue has been resolved.


















• In l2circuit connection scenario, when the STFPC/Ichip based FPC interconnect with

MX Series based FPC, PPP-CCC l2circuit connection will drop the small packets with

Ethernet length error. PR887098: This issue has been resolved.

• Because of the hardware limit, the feature "maximum-labels" on FPC can't exceed 3.

Whenever maximummpls label is configured as 4 or 5 on unsupported FPC, the

LDP/RSVP session will go down and cause MPLS traffic black hole for couple of

minutes. This dark windowwill remain till the unicast next hops are installed and

attached to the egress interfacewhere the label has been configured. After that MPLS

traffic will resume. PR890992: This issue has been resolved.

Routing Protocols

• With OSPFv3, PIMv6 or LDP configured, the periodic packet management daemon

(ppmd) takes responsibility for these protocols' adjacencies. In a rare condition, kernel

might send an invalid packet with a null destination in the message header to ppmd

process, causing ppmd process to crash and create a core file. PR802231: This issue

has been resolved.

• BFD triggered local-repair(RLI9007) not initiating immediately. RLI 9007 is applicable

from 12.2 onwards. PR825283: This issue has been resolved.

• Junos OS checks for mask-length mismatch for OSPF P2P-over-LAN interfaces, but

skips the check if an interface has /32mask configured. In a scenario with OSPF

configured between Juniper Networks platform and other vendors' platform, if a /32

mask IP address is configured on P2P-over-LAN OSPF interface of Juniper Networks

platform and a non /32mask IP address is configured on the peer, the OSPF neighbor

can establish but Kernel Routing Table (KRT) queue gets stuck. PR840122: This issue

has been resolved.

• In BGP scenario, the initial peer flaps and goes down then a new peer is established

which might cause an rpd core. PR840652: This issue has been resolved.

• Junos OS label block allocation can only return block size as power of 2 (e.g. 2, 4, 8,

16,...). In inter-asoption-bL2VPNscenario, routingprotocol daemon(RPD)core is seen

when the ASBR received a non-power-of-2 label block request from other vendor's

device. The core files could be seen by executing CLI command show system

core-dumps. In the fix, Junos OS can now support any size. PR848848: This issue has

been resolved.

• In an invalid subnet configuration on amulticast group, when you performed a commit

or commit check, the routing protocol process (rpd) crashed and generated core files.


• Multicast packets coming with source address as 0.0.0.0, might cause the RPD to

crash. PR866800: This issue has been resolved.

• If the SNMPMIB for BGP is walked, the AFI=1, SAFI=5 entries are missing. If an SNMP

"get" is performed, the values can be retrieved.PR868424: This issuehasbeen resolved.

• In inter-AS Option-B L2VPN scenario, the ASBRmight create a L2VPN cloned transit

route incorrectly due to a cloned route is a Juniper Networks specific mpls.0 route

which Junos OS creates on the penultimate hop router. Then in a rare case, routing

protocol daemon (rpd) tries to delete the L2VPN cloned transit route (inmpls.0 table)
















multiple times. After this, routing protocol process (rpd) crashes and creates a core

file. PR878437: This issue has been resolved.

• Returned attribute values are not in the defined value range of the mib

bgp4PathAttrASPathSegment. PR882407: This issue has been resolved.

• RPD CPU utilization keeps 100% due to "BGP resync" task when BGP is configured

with no neighbor and NSR is configured. id@router> show configure routing-options

nonstop-routing; id@router> show configure protocols bgp { group bgp-group { type

internal; inactive: neighbor 1.0.0.1; } } PR884602: This issue has been resolved.

• RPDmay crash on the newmaster Routing Engine after Routing Engine switchover.

The issue is NSR related, and it happens due to the bad BGP route data structure on

backup Routing Engine. PR885305: This issue has been resolved.

• The downstream PE router's RPF_neighbor(S) on the MDT reverts back to

mRIB.next_hop(S) rather than the Assert(S,G)Winner when their PPT expires.



• The issue is seen because of receiving malformed LCP configure-request packet with

bad option length from PPP client. In this case when router tries to generate

configure-nak it crashed. As a fix, check is added to discard suchmalformed

configure-request packets. PR872289: This issue has been resolved.

• Output interface' shownas 'Unknown'under showservicesaccounting flow-detail.issue

has been analysed RCA;-At the timewhen a flow is created in PICmemory, if the route

to the destination IP(in the flow) is not known, we set a flag indicating that there is no

route to Destination IP in the flow structure. When the flows are queried using "show

service accounting flow-detail" picinfo daemon inspects this flag for each flow and

prints the Output interface as "Unknown" if this flag is set. Now, after route record for

that flow is downloaded to the Service PIC, the flow structure is updated to reflect the

corresponding output interface, but, the above flag is NOTUNSET. So, picinfo daemon

continues to print the output interface as "unknown" whenever "show services

accounting flow-detail" is executed. PR890324: This issue has been resolved.

VPNs

• Wrong data type for MIB object "mplsL3VpnVrfRteXCPointer". PR866259: This issue

has been resolved.

• If a logical interface is taken out of VPLS or L2VPN Pseudowire Routing Instance and

placed in protocol l2circuit, after the above configuration changes are done in one

commit, routing protocol daemon (rpd) crashes and dumps core. PR872631: This issue

has been resolved.

Resolved Issues in 13.1R2


• A fewmemory leaks havebeen fixed in the class of service process.PR811613: This issue

has been resolved.
















• ConfiguringClassifiersundergroups,might result in class-of-serviceprocess togenerate

a core file. Work-around is to avoid configuring Classifiers under groups. PR841365:


• This seems to be hard to reproduce and noticed only once after GRES.When the cosd

restarts (due to the GRES test you performed), cosd reconciles the configurations

pushed to the Packet Forwarding Engine with configuration read from CLI and tries to

reuse the object ID. In this case, it was trying to insert the same ID twice. PR848666:



• MPLS forwarding table filter (ftf) not getting linked in JTREEafter router or FPC reboot.


General Routing

• Prior to this change, the L2TP sessions with cos/ firewall attachments fail to come up

when the L2TP Access Concentrator (LAC) is reachable over a unilist nexthop.


• The 'RL-dropped' lines of show interfaces queue aremissing when the PIC is bounced.


• ThePacketForwardingEnginemightcrashwhen receivingTCPpacketswithan incorrect

format. PR817318: This issue has been resolved.

• VPLS traffic gets flooded back over the ingress interface on the local PE as the

split-horizon gets disabled upon interface flap. PR818926: This issue has been resolved.

• The rpd on the backup Routing Engine might crash when it receives a malformed

message from themaster. This can occur at high scale with nonstop active routing

(NSR) enabled when a large flood of updates are being sent to the backup Routing

Engine. There is no workaround to avoid the problem, but it is rare and the backup rpd

will restart and the systemwill recover without intervention. PR830057: This issue has

been resolved.

• An FPCmight rebootwhen a core file is requested and the /var partition does not have

sufficient space to store the core file. PR835047: This issue has been resolved.

• After graceful Routing Engine switchover (GRES), when a routing instance is first

deactivated and then activated, 4xOC48 IQE PICmight reboot unexpectedly. This is

caused by a problem in channel allocation for the 4xOC48 PIC logical interfaces in

kernel. PR841822: This issue has been resolved.

• Themlfr/mlppp interfacesarenot reachableafter FPC(primaryMSPIC) restart followed

bydeactivateandactivate routing instanceorGRES followedbydeactivateandactivate

routing instance. This is because link FPC does not have the interfaces programmed

towards the bundle. PR847278: This issue has been resolved.

• Distributedprotocol adjacencies (LFM/BFD/etc)might experienceadelay in keepalives

transmission and/or processing due to a prolongedCPUusage on the FPCmicrokernel

on T4000Type 5-3D FPCs. The delay in keepalive transmission/processingmay result

in amis-diagnosis of a link fault by the peer devices. The issue is seen several seconds

















after an Routing Engine mastership switch with nonstop active routing enabled and

the fault condition will clear after a couple of minutes. PR849148: This issue has been

resolved.

• FPC or PIC connects to Routing Engine Kernel for the first time when it comes up or

reconnects during connection trip. After the connection is establishedwith theRouting

Engine, if FPC/PIC does not respond kernel for 300 seconds, a timer is triggered to

disconnect the Routing Engine from FPC/PIC. In a particular race condition between

kernel processing received data on the connection and the fired timer trying to close

the connection, kernel crashes and generates a core file. FPC/PIC's slow responsemay

be attributed to high traffic or a faulty hardware. Before kernel crash, the following

logs could be seen: fpc3 LCHIP(3): 1 new Lin SIF ins eope errors fpc3 LIN(3): PIC HSR is

not OK, LCHIP(3) <- PIC 3 HSR 1. PR853296: This issue has been resolved.

• If routing-instance is popping thempls label through vt tunnel interface and the egress

interface MTU of the vrf needs fragmentation and the dont-fragment bit is set in the

ipv4 header, the egress vrf interfacemight stop forwarding traffic. The following syslog

message will be reported fpc4 LCHIP(3): 1 new errors in LSIF To recover from this

conditionyoucaneitherbring the interfacedownviadisable knobordeactivate/activate

the interface from the configuration. The following platforms are exposed to this

condition:M320 (excluding E3 FPCs),T/TX systems (excluding ES FPCs and FPC Type

5) . PR854806: This issue has been resolved.

• In the T4000 Type 5 FPC platform, aperture management can lead to a collision

between the sched tick timer and asic driver interrupt handlers, whichwill result in FPC

crashes. PR857167: This issue has been resolved.

• BOOTP request packets might get dropped because of the DDOS protection feature

on MX Series routers with MPCs and MICs. In this case, the bootp packet is coming

with 1 byte option. So the length of bootp become 241 which is larger than 240. Then

the Packet Forwarding Engine will identify it not as BOOTP as per the current DDOS

algorithm, and tries to parse it asDHCP. Since thepacket lacks the options fieldswhich

need for DHCP, then pfe_nhdb_dhcpv4_msg_type() marks it as DHCPNOMSGTYPE.


• When a prefix next-hop address resolution requires a recursive lookup, the next-hop

might not be updated correctly after an egress interface is disabled. PR862989: This


• Junos OSmissing MIBs and ENTITY-MIB(rfc2737) and

IANA-ADDRESS-FAMILY-NUMBERS-MIB. PR863296: This issue has been resolved.

• When using BGP Flow Spec with rate-limit option, even though the value is in

Bytes/second, the value being programmed is in bits/second. PR864496: This issue

has been resolved.

• Outputof showsubscribersphysical-interfaceaexdisplaysmultipleAE links.PR864555:


• On T Series platforms with ES-FPC equipped, while adding and deleting source-class

usage (scu) or unicast Reverse path forwarding (uRPF) configuration, Jtree memory

leakand the followingerrormessagescouldbeobserved: fpc0nh_jtree_fe_posthandler:

RNH_TABLE 1missing ext rnh .PR869651: This issue has been resolved.

















High Availability and Resiliency

• The backupRouting Engine sends Arp 128.0.0.6 to the Packet Forwarding Engine, then

they are counted as "unknown" on show pfe statistics traffic. PR830661: This issue has

been resolved.

Infrastructure

• Delay in bringing online an FPCafter it is inserted into the chassis.PR853304: This issue

has been resolved.

• TCP is mistakenly enabling re-transmit timer for pure ACK's which is causing the FPC

to reboot. PR858489: This issue has been resolved.

• When a SONET interface with PPP encapsulation is used as forwarding next hop for

the IPv6 remote router loopback address on IPv6 BGP sessions, if the SONET link is

down, the IPv6 BGP session might flap at same time although there is valid route via

other interface. PR863462: This issue has been resolved.


• There can be amismatch between the ifIndex value on IF-MIB-ifName and the ifIndex

valueonSONET-APS-MIB-apsMapGroupNameandapsMapEntry.PR771877:This issue

has been resolved.

• Faulty SCG causes continuous interrupts to HCFPCmaking its CPU Utilization 100%

and unusable for any service. As a fix the monitoring mode for the SCG is changed to

polling statusofSCGdevice rather then interruptsbasedawakeandmonitoring system.


• Cannot assign and delete the ipv6 address assigned to the interface in eui-64 format.


• Interface hold-time-down is not working properly for PIC type 10x10GE(LAN/WAN)

SFPP. PR859102: This issue has been resolved.


• DHCPv6 fails for clients using DUID type 2 (Vendor-assigned unique ID). The software

wasusing theDUID toextractMACaddress information.PR838404:This issuehasbeen

resolved.


• 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, itwill lead to thegenerationof a core file.PR739375:This issuehasbeen resolved.

• Thecustomersupgradingnetworkusing features involvingnonpenultimateHopPopping

Behavior andOut-of-BandMapping shouldupgrade routers involved together to Junos

OS Release 13.1 or later releases. PR852808: This issue has been resolved.


















• The rpd generates a core file on the backup Routing Engine with

rsvp_mirror_telink_attempt_resolve.PR859602: This issue has been resolved.

• ASBRmight not rewrite EXP correctly for egress MPLS packets on the Inter-AS link for

the eBGP-LU LSP if the eBGP session is amultihop BGP session. PR864914: This issue

has been resolved.


• Under certain conditions, duplicate SNMP indexes might be assigned to different

interfaces by kernel to mib2d (Management Information Base II process). This might

causemib2d andother processes such as lacpd (LACPprocess) to crash and generate

core files. PR836823: This issue has been resolved.


• On the JCS-1200 RE-JCS-1X2400-48G-S Routing Engine configuration of the MAC

address on the external interfaces, em0 and em1 is not allowed. You cannot configure

the MAC address on fxp0 on the other Routing Engines supported on the JCS-1200 as

well. Therefore, the Junos OS CLI to configure the MAC address on the em0 and em1

interfaces has been disabled. PR770899: This issue has been resolved.

• The showroute forwarding-table commandwouldonly display<= 16ecmppathswhen

CBF is used. PR832999: This issue has been resolved.

• The deny commands not working for show route community-name. PR836624: This


• When a junoscript get-configuration RPC query, by default the query is done on

candidateDB, amgdprocess is spawned to handle this request. Nowat the same time

via another session if the configuration is deleted it is possible for the above spawned

mgd process performing the junoscript query to crash. Themgd process crashes while

accessing a null parent which contained an object previously which was deleted. The

fix addresses this by not exporting the object which has no parent. PR844795: This


• Any operation performed in private mode after the system is brought up with a scaled

configuration might cause anmgd to generate a core file. PR855990: This issue has

been resolved.

• OnMX Series routers with MPCs and MICs, error message “LUCHIP(x) has no shadow

data for IDMEM[0x00xxxx]" might be seen. PR859424: This issue has been resolved.

Routing Protocols

• If LDP-SYNC hold-down timer is configured under the IS-IS interfaces, after

configuration change the IS-IS interfaces can go to hold-down state. PR831871: This


• In IS-IS scenario, with graceful Routing Engine switchover (GRES) and nonstop active

routing (NSR) enabled, after Routing Engine switchover, in very rare case, the routing

protocol process (rpd) might crash and generate a core file on the newmaster (old

backup) Routing Engine. This crash happens upon the IS-IS LSP generation due to

memory corruption. PR841558: This issue has been resolved.



















• IS-IS reports prefix-export-limit exceeded even though the number of exported routes

is smaller than the configured value of prefix-export-limit. PR844224: This issue has

been resolved.

• Under certain conditions, moving a link that has BFD clients can cause stale BFD entry

for the old link. PR846981: This issue has been resolved.

• The upstream interface of multicast rpf not matching multicast route in Inter-AS PIM.


• When an import-policy change rejects a BGP-route previously contributing to

BGP-Multipath formation, the peer active-route-counters in the output of the show

bgpneighbor commandmight not get updatedcorrectly.PR855857:This issuehasbeen

resolved.

• Routing protocol process (rpd) crashes and generates core files when nonbgp routes

(e.g. static route) are advertised as add-path route. PR859307: This issue has been

resolved.

• In VPLSmulti-homing environment, with same route-distinguisher configured for the

VPLS primary PE and the backup PE, routing protocol process (rpd) might crash and

generate a core file in each of following two scenarios: 1 - On VPLS , the backup PE,

enable "advertise-external" knob, then rpd crashes and generates a core file on the

backup PE. 2 - On VPLS primary PE, enable "advertise-external" knob, after disabling

the VPLS interface, rpd process crashes and generates a core file on primary PE.When

issue happens, the following behavior could be observed:

user@router> show bgp neighborerror: the routing subsystem is not runninguser@router> show vpls connectionserror: the routing subsystem is not running


• MPLS OAM programs BFD, it does not provide the source address(no change in

behavior). In BFD before programming PPMD it queries kernel for the source address

matching the prefix of the destination address on a interface. BFD programs PPMD

with this source address. PPMDwill construct BFD packet with BFD provided source

address in the IP header. PR870421: This issue has been resolved.


• The spd generates a core file during switchover with CGAT configuration. PR854206:


VPNs

• Deleted logical interfaces might not be freed due to references in MVPN. PR851265:


• Whenmulticast omit-wildcard-address is configured on a route-reflector for theMVPN

address families, Leaf-AD route NLRIs are not reflected correctly in the newer, and

standardized format. The Leaf-AD routes transmitted from the RR in the new format

will have invalid Leaf-IP fields in the NLRI set to 0.0.0.0. As a result, ingress PEs might

















fail to properly identify all egress PEs and thus fail to update provider-tunnel state to

deliver traffic to those egress PEs. PR854096: This issue has been resolved.

• When L2circuit/L2VPN is not configured and the user requests for PW object info

throughMIB, L2circuit/l2vpn is creating invalid job,which leads to rpd crash.PR854416:




on page 3

•




on page 37





Errata and Changes in Documentation for Junos OS Release 13.1 for M Series, MX Series, and TSeries Routers

Errata

Hardware

• The Protocols and Applications Supported by MX240, MX480, MX960, MX2010, and

MX2020 MPCs topic erroneously states that support was introduced in Junos OS

Release 10.4 for IEEE 802.3ah OAM (discovery and link monitoring, fault signaling and

detection, and remote loopback). In fact, this support was introduced in Junos OS

Release 11.1.

Class of Service

• The Example: Configuring Scheduling Modes on Aggregated Interfaces topic fails to

mention the following additional information regarding the parameters that are scaled

for aggregated interfacemember links when the scheduler parameters are configured

using scheduler maps:

Apart from transmit rate and buffer size that are scaled when the parameters are

configured using scheduler maps, shaping rate is also scaled if you configure it in bits

per second (bps). Shaping rate is not scaled if you configure it as a percentage of the

available interface bandwidth.

[Class of Service, Schedulers on Aggregated Ethernet and SONET/SDH Interfaces]

• The enhanced-policer topic in the Junos OS Subscriber Access Configuration Guide 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.


Errata and Changes in Documentation for Junos OS Release 13.1 for M Series, MX Series, and T Series Routers




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 statistics that are

within specification; when the policer action is non-discard (loss-priority or

forwarding-class), the statistics 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.

• The followingadditional information regarding theshaping rategranularity fordifferent

MPCs applies to the CoS Features on MIC and MPC Interfaces Overview topic:

The shaping rate granularity for MX Series routers with the MPC3E and MPC4E is

approximately 293-300 Kbps. For routers with other MPCs (MX Series-based FPCs),

the shaping rate granularity is 250 Kbps. The predefined shaping rates for theseMPCs

are the next multiple of these shaping rate granularity values. The expected deviation

from the predefined shaping rates is 5 to 10 percent.

[Class of Service, CoS on MIC and MPC Interfaces ]

DTCP-Initiated Subscriber Secure Policy

• TheDTCP LIST topic in the Junos OS Subscriber Access Configuration Guide for Release

13.1 does not include the following information:

Youmust include the Flags field in DTCP LISTmessages, and the Flags field must be

set to BOTH. For example, Flags: BOTH.

Infrastructure

• The following additional information regarding the behavior of the accept-data

statement for MC-LAG in an active-active bridge domain applies to the Active-Active

Bridging and VRRP over IRB Functionality on MX Series Routers Overview topic:

For a multichassis link aggregation group (MC-LAG) configured in an active-active

bridgedomain andwithVRRPconfiguredover an integrated routing andbridging (IRB)

interface, youmust include the accept-data statement at the [edit interfaces

interface-nameunit logical-unit-number family inet addressaddressvrrp-groupgroup-id]

hierarchy level to enable the router that functions as the master router to accept all

packets destined for the virtual IP address.

On an MC-LAG, if youmodify the source MAC address to be the virtual MAC address,

youmust specify the virtual IP address as the source IP address instead of the physical

IP address. In such a case, the accept-data option is required for VRRP to prevent ARP

from performing an incorrect mapping between IP and MAC addresses for customer

edge (CE) devices. The accept-data attribute is needed for VRRP over IRB interfaces



inMC-LAGtoenableOSPForother Layer 3protocols andapplications toworkproperly

over multi-chassis aggregated Ethernet (mc-aeX) interfaces.

[Network Interfaces, Ethernet Interfaces]

• The following additional information regarding the support of vlan-id none statement

for MC-LAG applies to the Active-Active Bridging and VRRP over IRB Functionality on

MX Series Routers Overview topic:

In an IPv6 network, you cannot configure a multichassis link aggregation group

(MC-LAG) inanactive-activebridgedomain if you specified the vlan-idnone statement

at [edit bridge-domain bd-name] hierarchy level. The vlan-id none statement that

enables the removal of the incoming VLAN tags identifying a Layer 2 logical interface

when packets are sent over VPLS pseudowires is not supported for IPv6 packets in an

MC-LAG.


• The following additional information regarding the configuration of peer IP addresses

for ICCP peers andmultichassis protection forMC-LAGapplies to theConfiguring ICCP

for MC-LAG topic:

For Inter-Chassis Control Protocol (ICCP) in a multichassis link aggregation group

(MC-LAG) configured in an active-active bridge domain, youmust ensure that you

configure thesamepeer IPaddresshosting theMC-LAGby including thepeer ip-address

statement at the [edit protocols iccp] hierarchy level and themulti-chassis-protection

peer ip-address statement at the [edit interfaces interface-name] hierarchy level.

Multichassis protection reduces the configuration at the logical interface level for MX

Series routers with multichassis aggregated Ethernet (MC-AE) interfaces. If the ICCP

is UP and the interchassis data link (ICL) comes UP, the router configured as standby

will bring up the MC-AE interfaces shared with the peer active-active node specified

by the peer statement.

For example, the following statements illustrate how the same peer IP address can

be configured for both the ICCP peer andmultichassis protection link:

set interfaces ae1 unit 0multi-chassis-protection 10.255.34.112 interface ae0.0set protocols iccp peer 10.255.34.112 redundancy-group-id-list 1

Although you can commit an MC-LAG configuration with various parameters defined

for it, youcanconfiguremultichassisprotectionbetween twopeerswithoutconfiguring

the ICCP peer address. You can also configure multiple ICCP peers and commit such

a configuration.





• The validate option for the command request system software add only works on

systems that do not have graceful-switchover (GRES) enabled. To use the validate

option on a systemwith GRES, either disable GRES for the duration of the installation,

or install using thecommand requestsystemsoftware in-service-upgrade,which requires

nonstop active routing (NSR) to be enabled when using GRES.

Network Management

• The Supported Network Management Standards topic fails to mention the following


On MX Series routers with MPC/MIC interfaces that use the ATMMIC with SFP, Junos

OS substantially supports the following RFCs:

• RFC 5603, PWE3 MIB

• RFC 5601, PW-FRAME-MIB

[Junos OS Supported Standards]

• Thedocumentation fails toclearlydescribe thecharacters that canbeused forSNMPv3

authentication passwords. Besides numbers, uppercase letters, and lowercase letters,

the following special characters are supported:

, . / \ < > ; : ' [ ] { } ~ ! @ # $% ^ * _ + = - `

In addition, the following special characters are also supported, but youmust enclose

themwithin quotation marks (“”) if you enter them on the CLI; if you use a Network

Management System to enter the password, the quotation marks are not required:

| & ( ) ?

Thedocumentationalso fails to clearly state that characters enteredby simultaneously

pressing the Ctrl key and additional keys are not supported. [PR/883083: This issue

has been resolved]



Routing Protocols

• The following additional information regarding the behavior of MAC addresses in a

VPLSdual-homednetworkwithMSTPapplies to theBridge Priority for Election of Root

Bridge and Designated Bridge topic:

Consider a sample scenario in which a dual-homed customer edge (CE) router is

connected to two other provider edge (PE) routers, which function as the VPLS PE

routers, with MTSP enabled on all these routers, and with the CE router operating as

the root bridge. Integrated Routing and Bridging (IRB) interface is configured for the

VPLS routing instances on the routers. In such a network, the MAC addresses that are

learned in the VPLS domain continuouslymove between the LSI or virtual tunnel (VT)

interfaces and the VPLS interfaces on both the PE routers. To avoid the continuous

movement of the MAC addresses, youmust configure root protection by including the

no-root-port statement at the [edit routing-instances routing-instance-name protocols

mstp interface interface-name] hierarchy level and configure the bridge priority as zero

by including the bridge priority 0 statement at the [edit routing-instances

routing-instance-name protocolsmstp] hierarchy level on the PE routers. This

configuration on the PE routers is required to prevent the CE-side facing interfaces

from becoming the route bridge.

[Layer 2 Configuration Guide]

• The Supported MPLS Standards topic fails to mention the following additional

information:

On MX Series routers with the Channelized OC3/STM1 (Multi-Rate) Circuit Emulation

MIC with SFP, Junos OS substantially supports RFC 4385, Pseudowire Emulation

Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN.


• TheSupportedCarrier-of-Carriers and InterproviderVPNStandards topic fails tomention

the following additional information:


MIC with SFP, Junos OS substantially supports the following RFCs:

• RFC 3985, PseudoWire Emulation Edge-to-Edge (PWE3) Architecture

• RFC 3916, Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)


• The Supported IPv4, TCP, and UDP Standards topic fails to mention the following


Junos OS substantially supports RFC 950, Internet Standard Subnetting Procedure.


• TheOSPF Configuration Guide incorrectly includes the transmit-interval statement at

the [edit protocols ospf area area interface interface-name] hierarchy level. The

transmit-interval statement at this hierarchy level is deprecated in the Junos OS

command-line interface.



[OSPF Configuration Guide]


• The Supported IPsec and IKE Standards topic fails to mention the following additional

information:

On routers equipped with one or more Adaptive Services PICs (both standalone and

integrated versions) or Multiservices PICs or DPCs, Junos OS substantially supports

the following RFCs:

• RFC 2451, The ESP CBC-Mode Cipher Algorithms

• RFC 2460, Internet Protocol, Version 6 (IPv6)

• RFC 3193, Securing L2TP using IPsec

• RFC 3947, Negotiation of NAT-Traversal in the IKE

• RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating

Security Payload (ESP) and Authentication Header (AH)

• RFC 4306, Internet Key Exchange (IKEv2) Protocol

• RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2

(IKEv2)

• RFC 4308, Cryptographic Suites for IPsec

NOTE: Only Suite VPN-A is supported in Junos OS.

• RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating

Security Payload (ESP) and Authentication Header (AH)

• RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

RFC 4301, Security Architecture for the Internet Protocol obsoletes RFC 2401.

RFC 4302, IP Authentication Header obsoletes RFC 2402.

RFC 4303, IP Encapsulating Security Payload (ESP) obsoletes RFC 2406.

RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating

Security Payload (ESP) and Authentication Header (AH) obsoletes RFC 2404 and RFC

2406.

RFC 4306, Internet Key Exchange (IKEv2) Protocol obsoletes RFC 2407, RFC 2408, and

RFC 2409.

Junos OS partially supports the following RFCs for IPsec and IKE:

• RFC 3526,More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key

Exchange (IKE)

• RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards

• RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2




• The show services stateful-firewall flow-analysis command should be included in the

System Basics and Services Command Reference Guide. This command displays

stateful firewall flow statistics.

• The show services stateful-firewall subscriber-analysis command should be included

in theSystemBasicsandServicesCommandReferenceGuide.This commanddisplays

information about the number of active subscribers on the service physical interface

card (PIC).

• In the Next-Generation Network Addressing Carrier-Grade NAT and IPv6 Solutions

Guide, the section “Configuring Address Pools for Network Address Port Translation”

should be revised as follows: The following variables should be added

Nr_Addr_PR_Prefix – Number of usable pre-NAT IPv4 subscriber addresses in a “from”

clause match condition Nr_Addr_PU_Prefix – Number of usable post-NAT IPv4

addresses configured in the NAT pool Rounded_Port_Range_Per_IP –

ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] * Block_Size The Forward Translation

formulas shouldbe: 1. Pr_Offset=Pr_Prefix-Base_Pr_Prefix 2.Pr_Port_Offset=Pr_Offset

* Block_Size 3. Rounded_Port_Range_Per_IP =

ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] * Block_Size 4. Pu_Prefix =

Base_Public_Prefix + floor(Pr_Port_Offset/Rounded_Port_Range_Per_IP) 5.

Pu_Start_Port = Pu_Port_Range_Start + (Pr_Port_Offset%

Rounded_Port_Range_Per_IP)TheReverseTranslation formulas shouldbe: 1. Pu_Offset

= Pu_Prefix - Base_Pu_Prefix 2. Pu_Port_Offset = (Pu_Offset *

Rounded_Port_Range_Per_IP) + (Pu_Actual_Port - Pu_Port_Range_Start) 3.

Subscriber_IP = Base_Pr_Prefix + floor(Pu_Port_Offset / Block_Size)

• The following informationshouldbeadded to thesyntaxof the “service-set (Services)”

configuration statement topic in the Services Interfaces Configuration Guide. This

information should appear under the service-set service-set-name level:

service-set-options {bypass-traffic-on-exceeding-flow-limits;bypass-traffic-on-pic-failure>;enable-asymmetric-traffic-processing;support-uni-directional-traffic;

}

This issue was being tracked by PR888803.

• The following information should replace Table 1 and the section “Sample Output” in

the “showservices stateful-firewall statististics” topic in theSystemBasics andServices

Command Reference:

Table 3: show services stateful-firewall statistics output fields

Field DescriptionField Name

Name of an adaptive services interface.Interface

Name of a service set.Service set



Table 3: show services stateful-firewall statistics output fields (continued)


Rule match counters for new flows:

• Rule Accepts—New flows accepted.

• Rule Discards—New flows discarded.

• Rule Rejects—New flows rejected.

New flows

Rule match counters for existing flows:

• Accepts—Match existing forward or watch flow.

• Drop—Match existing discard flow.

• Rejects—Match existing reject flow.

Existing flow typespacket counters

Hairpinning counters:

• SlowPathHairpinnedPackets—Slowpath packets thatwere hairpinned backto the internal network.

• Fast Path Hairpinned Packets—Fast path packets that were hairpinned backto the internal network.

HairpinningCounters

Drop counters:

• IP option—Packets dropped in IP options processing.

• TCP SYN defense—Packets dropped by SYN defender.

• NAT ports exhausted—Hidemode. The router has no available NetworkAddress Translation (NAT) ports for a given address or pool.

• Sessionsdroppeddue tosubscriber flow limit—Sessions droppedbecause thesubscriber’s flow limit was exceeded.

Drops

Total errors, categorized by protocol:

• IP—Total IP version 4 errors.

• TCP—Total Transmission Control Protocol (TCP) errors.

• UDP—Total User Datagram Protocol (UDP) errors.

• ICMP—Total Internet Control Message Protocol (ICMP) errors.

• Non-IP packets—Total non-IPv4 errors.

• ALG—Total application-level gateway (ALG) errors

Errors





IPv4 errors:

• IPpacket length inconsistencies—IPpacket length does notmatch the Layer 2reported length.

• Minimum IP header length check failures—Minimum IP header length is20 bytes. The received packet contains less than 20 bytes.

• ReassembledpacketexceedsmaximumIP length—After fragment reassembly,the reassembled IP packet length exceeds 65,535.

• Illegal source address 0—Source address is not a valid address. Invalidaddresses are, loopback, broadcast, multicast, and reserved addresses.Source address0, however, is allowed to support BOOTPand thedestinationaddress 0xffffffff.

• Illegal destination address 0—Destination address is not a valid address. Theaddress is reserved.

• TTL zero errors—Received packet had a time-to-live (TTL) value of 0.

• Illegal IP protocol number (0 or 255)—IP protocol is 0 or 255.

• Land attack—IP source address is the same as the destination address.

• Non-IPv4 packets—Packet was not IPv4. (Only IPv4 is supported.)

• Bad checksum—Packet had an invalid IP checksum.

• Illegal IP fragment length—Illegal fragment length. All fragments (other thanthe last fragment) must have a length that is a multiple of 8 bytes.

• IP fragment overlap—Fragments have overlapping fragment offsets.

• IP fragment reassembly timeout—Some of the fragments for an IP packetwere not received in time, and the reassembly handler dropped partialfragments.

• IP fragment limit exceeded: 0—Fragments that exceeded the limit.

• Unknown: 0—Unknown fragments.

IP Errors





TCP Errors





TCP protocol errors:

• TCP header length inconsistencies—Minimum TCP header length is 20 bytes,and the IP packet received does not contain at least 20 bytes.

• Source or destination port number is zero—TCP source or destination port iszero.

• Illegal sequence number and flags combinations—Dropped because of TCPerrors, such as an illegal sequence number, which causes an illogicalcombination of flags to be set.

• SYN attack (multiple SYNmessages seen for the same flow)—Multiple SYNpackets received for the same flow are treated as a SYN attack. The packetsmight be retransmitted SYN packets and therefore valid, but a large numberis cause for concern.

• First packet not a SYNmessage—First packets for a connection are not SYNpackets. These packets might originate from previous connections or fromsomeone performing an ACK/FIN scan.

• TCP port scan (TCP handshake, RST seen from server for SYN)—In the case ofa SYN defender, if an RST (reset) packet is received instead of a SYN/ACKmessage, someone is probably trying to scan the server. This behavior canresult in false alarms if the RST packet is not combined with an intrusiondetection service (IDS).

• Bad SYN cookie response—SYN cookie generates a SYN/ACKmessage forall incoming SYN packets. If the ACK received for the SYN/ACKmessagedoes not match, this counter is incremented.

• TCP reconstructor sequence number error—This counter is incremented in thefollowing cases:The TCP seqno is 0 and all the TCP flags are also 0.

The TCP seqno is 0 and FIN/PSH/URG TCP flags are set.

• TCP reconstructor retransmissions—This counter is incremented for theretransmitted packets during connection 3-way handshake.

• TCP partially opened connection timeout (SYN)—This counter is incrementedwhentheSYNDefender isenabledandthe3-wayhandshake isnotcompletedwithin the SYN DEFENDER TIMEOUT. The connection will be closed andresources will be released by sending RST to the responder.

• TCP partially opened connection timeout (SYN-ACK)—This counter isincremented when the SYN Defender is enabled and the 3-way handshakeis not completed within the SYN DEFENDER TIMEOUT. The connection willbe closed and resources will be released by sending RST to the responder.

• TCP partially closed connection reuse—Not supported.

• TCP 3-way error - client sent SYN+ACK—A SYN/ACK should be sent by theserver on receivingaSYN.This counter is incrementedwhen the firstmessagereceived from the initiator is SYN+ACK.

• TCP 3-way error - server sent ACK—ACK should be sent by the client onreceiving a SYN/ACK from the server. This counter is incremented when theACK is received from the Server instead of from the Client.

• TCP 3-way error - SYN seq number retransmissionmismatch—This counter isincrementedwhentheSYN is receivedagainwithadifferentsequencenumberfrom the first SYN sequence number.

• TCP 3-way error - RST seq numbermismatch—A reset could be received fromeither side. The server could sendaRSTon receiving aSYNor the client couldsend a RST on receiving SYN/ACK. This counter is incremented when theRST is receivedeither fromtheclientor serverwithanon-matching sequence





number.

• TCP 3-way error - FIN received—This counter is incremented when the FIN isreceived during the 3-way handshake.

• TCP 3-way error - invalid flags (PSH, URG, ECE, CWR)—This counter isincremented when any of the PSH, URG, ECE, or CWR flags were receivedduring the 3-way handshake.

• TCP 3-way error - SYN recvd but no client flows—This counter is incrementedwhen SYN is received but not from the connection initiator. The counter isnot incremented in the case of simultaneous open, when the SYN is receivedin both the directions.

• TCP 3-way error - first packet SYN+ACK—The first packet received wasSYN+ACK instead of SYN.

• TCP3-wayerror - firstpacketFIN+ACK—The first packet receivedwasFIN+ACKinstead of SYN.

• TCP 3-way error - first packet FIN—The first packet received was FIN insteadof SYN.

• TCP 3-way error - first packet RST—The first packet receivedwas RST insteadof SYN.

• TCP3-way error - first packet ACK—The first packet receivedwas ACK insteadof SYN.

• TCP 3-way error - first packet invalid flags (PSH, URG, ECE, CWR)—The firstpacket received had invalid flags.

• TCP Close error - no final ACK—This counter is incremented when ACK is notreceived after the FINs are received from both directions.

• TCPResumedFlow—Plain ACKs create flows if rulematch permits, and theseare classified asTCPResumedFlows. This counter is incremented in the caseof a TCP Resumed Flow.

UDP protocol errors:

• IPdata length less thanminimumUDPheader length(8bytes)—MinimumUDPheader length is 8 bytes. The received IP packets contain less than 8 bytes.

• Source or destination port is zero—UDP source or destination port is 0.

• UDP port scan (ICMP error seen for UDP flow)—ICMP error is received for aUDP flow. This could be a genuine UDP flow, but it is counted as an error.

UDP Errors

ICMP protocol errors:

• IP data length less thanminimum ICMPheader length (8 bytes)—ICMP headerlength is 8 bytes. This counter is incremented when received IP packetscontain less than 8 bytes.

• ICMP error length inconsistencies—Minimum length of an ICMP error packetis48bytes, and themaximumlength is 576bytes. This counter is incrementedwhen the received ICMP error falls outside this range.

• Duplicate ping sequence number—Received ping packet has a duplicatesequence number.

• Mismatchedpingsequencenumber—Receivedpingpacket has amismatchedsequence number.

• Nomatching flow—Nomatching existing flow was found for the ICMP error.

ICMP Errors





Accumulationofall theapplication-level gatewayprotocol (ALG)dropscountedseparately in the ALG context:

• BOOTP—Bootstrap protocol errors

• DCE-RPC—Distributed Computing Environment-Remote Procedure Callprotocols errors

• DCE-RPCportmap—DistributedComputing Environment-Remote ProcedureCall protocols portmap service errors

• DNS—Domain Name System protocol errors

• Exec—Exec errors

• FTP—File Transfer Protocol errors

• H323—H.323 standards errors

• ICMP—Internet Control Message Protocol errors

• IIOP—Internet Inter-ORB Protocol errors

• Login—Login errors

• NetBIOS—NetBIOS errors

• Netshow—NetShow errors

• Real Audio—RealAudio errors

• RPC—Remote Procedure Call protocol errors

• RPC portmap—Remote Procedure Call protocol portmap service errors

• RTSP—Real-Time Streaming Protocol errors

• Shell—Shell errors

• SIP—Session Initiation Protocol errors

• SNMP—Simple Network Management Protocol errors

• SQLNet—SQLNet errors

• TFTP—Trivial File Transfer Protocol errors

• Traceroute—Traceroute errors

ALG errors

• Maximum Ingress Drop flows allowed-–Maximum number of ingress flowdrops allowed.

• MaximumEgressDropflowsallowed-–Maximumnumberofegress flowdropsallowed.

• Current Ingress Drop flows-–Current number of ingress flow drops.

• Current Egress Drop flows-–Current number of egress flow drops.

• Ingress Drop Flow limit drops count-–Number of ingress flow drops due tomaximum number of ingress flow drops being exceeded.

• Egress Drop Flow limit drops count-–Number of egress flow drops due tomaximum number of egress flow drops being exceeded.

Drop Flows



user@host> show services stateful-firewall statistics extensiveInterface: ms-1/3/0 Service set: interface-svc-set New flows: Rule Accepts: 907, Rule Discards: 0, Rule Rejects: 0 Existing flow types packet counters: Accepts: 3535, Drop: 0, Rejects: 0 Haripinning counters: Slow Path Hairpinned Packets: 0, Fast Path Hairpinned Packets: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0, Sessions dropped due to subscriber flow limit: 0

Errors: IP: 0, TCP: 0 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 IP fragment limit exceeded:0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combination: 0 SYN attack (multiple SYN messages seen for the same flow): 0 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 TCP reconstructor sequence number error: 0 TCP reconstructor retransmissions: 0 TCP partially opened connection timeout (SYN): 0 TCP partially opened connection timeout (SYN-ACK): 0 TCP partially closed connection reuse: 0 TCP 3-way error - client sent SYN+ACK: 0 TCP 3-way error - server sent ACK: 0 TCP 3-way error - SYN seq number retransmission mismatch: 0 TCP 3-way error - RST seq number mismatch: 0 TCP 3-way error - FIN received: 0 TCP 3-way error - invalid flags (PSH, URG, ECE, CWR): 0 TCP 3-way error - SYN recvd but no client flows: 0 TCP 3-way error - first packet SYN+ACK: 0 TCP 3-way error - first packet FIN+ACK: 0 TCP 3-way error - first packet FIN: 0 TCP 3-way error - first packet RST: 0 TCP 3-way error - first packet ACK: 0 TCP 3-way error - first packet invalid flags (PSH, URG, ECE, CWR): 0 TCP Close error - no final ACK: 0 TCP Resumed Flow: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0



Source or destination port is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 No matching flow: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 H323: 0, ICMP: 0, IIOP: 0 Login: 0, NetBIOS: 0, Netshow: 0 Real Audio: 0, RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0, SIP: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0 Drop Flows: Maximum Ingress Drop flows allowed: 20 Maximum Egress Drop flows allowed: 20 Current Ingress Drop flows: 0 Current Egress Drop flows: 0 Ingress Drop Flow limit drops count: 0 Egress Drop Flow limit drops count: 0

**If max-drop-flows is not configured, the following is shown** Drop Flows: Maximum Ingress Drop flows allowed: Default Maximum Egress Drop flows allowed: Default

• The following information should be added after the second paragraph of the

“Configuring Inline Sampling” topic in the Services Interfaces Configuration Guide:

The following limitations exist for inline sampling:

• Flow records and templates cannot be exported if the flow collector is reachable

through any management interface.

• The flow collector should be reachable through the default routing table (inet.0 or

inet6.0). If the flow collector is reachable via a non-default VPN routing and

forwarding table (VRF), flow records and templates cannot be exported.

• If the destination of the sampled flow is reachable throughmultiple paths, the

IP_NEXT_HOP (Element ID 15) andOUTPUT_SNMP (Element ID 14) in the IPv4 flow

record would be set to the Gateway Address and SNMP Index of the first path seen

in the forwarding table.

• If the destination of the sampled flow is reachable throughmultiple paths, the

IP_NEXT_HOP(Element ID 15) andOUTPUT_SNMP (Element ID 14) in the IPv6 flow

records would be set to 0.

• Theuser-definedsampling instancegetsprecedenceover theglobal instance.When

a user-defined sampling instance is attached to the FPC, the global instance is

removed fromtheFPCand theuser-defined sampling instance is applied to theFPC.

• The Incoming Interface (IIF) andOutgoing Interface (OIF) shouldbepart of the same

VRF. If OIF is in a different VRF, DST_MASK (Element ID 13), DST_AS (Element ID



17), IP_NEXT_HOP (Element ID 15), and OUTPUT_SNMP (Element ID 14) would be

set to 0 in the flow records.

• EachLookupChip (LU)maintainsandexports flows independentofother LUs.Traffic

received on amedia interface is distributed across all LUs in a multi-LU platform. It

is likely that a single flow will be processed bymultiple LUs. Therefore, each LU

creates a unique flow and exports it to the flow collector. This can cause duplicate

flows records to be seen on the flow collector. The flow collector should aggregate

PKTS_COUNT and BYTES_COUNT for duplicate flow records to derive a single flow

record.

This issue is being tracked by PR907991

• The System Basics and Services Command Reference should include the following

commands in the chapter “Dynamic Application Awareness Operational Mode

Commands”:

request services application-identification application: Copy, disable, or enable a

predefined application signature.

request services application-identification group: Copy, disable, or enable a predefined

application signature group.

showservicesapplication-identificationapplication: Displaydetailed informationabout

aspecifiedapplication signature, all application signatures, or a summaryof theexisting

application signatures andnestedapplication signatures. Both customandpredefined

application signatures and nested application signatures can be displayed.

showservicesapplication-identificationgroup: Displaydetailedor summary information

about a specified application signature group or all application signature groups. Both

custom and predefined application signature groups can be displayed.

show services application-identification version: Display the Junos OS application

package version.

• The following command should appear in the network address operational mode

commands:

clear services nat statistics<interface interface-name><service-set service-set-name>

The <interface interface-name> option clears NAT statistics for the specified interface

only.

The<service-setservice-set-name>optionclearsNATstatistics for the specified service

set only.

The clear services inline nat statistics command should include the following option:

<interface interface-name>

The <interface interface-name> option clears inline NAT statistics for the specified

interface only.



SSH Prompt Changes

The shell prompt for SSH has changed. There are different prompts for SSH versions 1

and 2. The changes can affect screen-scraping scripts.

The SSH prompt has changed from:

$ ssh user@[email protected]'s password:

To this prompt for SSHv2:

$ ssh user@hostPassword:

To this prompt for SSHv1:

$ ssh -1 localhostPassword:Response:

Additionally, the system response to invalid credentials has changed. Previously, a

message displayed upon entering invalid credentials.

[email protected]'s password:Permission denied, please try again.

Now, if invalid credentials are entered, there is nomessage, and the login prompt simply

displays again.

[email protected]'s password:[email protected]'s password:

SSH Syslog Messages

Some syslog messages related to SSH authentication decisions have changed.

Failed login attempt previous message:

* sshd[84724]: Failed password for regress from 10.9.0.25 port 54118 ssh2

Failed login attempt newmessage:

* sshd[3587]: error: PAM: authentication error for regress from 172.24.26.189

Successful login previous message:

* sshd[26735]: Accepted password for regress from 172.24.26.189 port 22356 ssh2

Successful login newmessage:

* sshd[12345]: Accepted keyboard-interactive/pam for rad_user from 10.209.6.28 port4008 ssh2



Subscriber Access Configuration Guide

• The Example: HTTP ServiceWithin a Service Set topic in the Subscriber Access

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

• RADIUS VSAs Not Documented in Subscriber Access Guide (MX Seriesrouters)—Several supported Juniper Networks VSAs are missing from the Junos OS

Release 13.1 Subscriber Access Configuration Guide. The following partial tables show

themissing VSAs.

Table 4: Supported Juniper Networks VSAs

DynamicCoASupportValueDescriptionAttribute Name

AttributeNumber

Nointeger:

• 0 = disable

• 1 = enable

Whether input statistics are enabled onclient interface.

Ingress-Statistics26-12

Nointeger:

• 0 = disable

• 1 = enable

Whether output statistics are enabledon client interface.

Egress-Statistics26-13

Nostring: bundle-nameThe SSC service bundle.Service-Bundle26-31



Table 4: Supported Juniper Networks VSAs (continued)


AttributeNumber

Nointeger:

• 0 = do not ignore

• 1 = ignore

State of the Ignore Don’t Fragment (DF)bit on client interface

Ignore-DF-Bit26-70

NostringIndication of user’s connection.Tx-Connect-Speed26-162

NostringIndication of user’s connection.Rx-Connect-Speed26-163

Nointeger: 4-octet

• 1 = dynamic-profile

• 2 = op-script

Indicationof serviceactivation type. Thisis a tagged attribute.

Service-Activate-Type26-173

NostringEnables theRadius server tooverride theclient dynamic profile in theAccess-Accept message.

Client-Profile-Name26-174

Table 5: AAA AccessMessages—Supported RADIUS Attributes and Juniper Networks VSAs

DisconnectRequest

CoARequest

AccessChallenge

AccessReject

AccessAccept

AccessRequestAttribute Name

AttributeNumber

––––✓–Ingress-Statistics26-12

––––✓–Egress-Statistics26-13

––––✓–Service-Bundle26-31

––––✓–Ignore-DF-Bit26-70

–––––✓Tx-Connect-Speed26-162

–––––✓Rx-Connect-Speed26-163

–✓––✓–Service-Activate-Type26-173

––––✓–Client-Profile-Name26-174

Table6:AAAAccountingMessages—SupportedRADIUSAttributesandJuniperNetworksVSAs

Acct OffAcct OnInterim AcctAcct StopAcct StartAttribute NameAttribute Number

––✓✓✓User-Name1

––✓✓✓Tx-Connect-Speed26-162



Table 6: AAA AccountingMessages—Supported RADIUS Attributes and Juniper NetworksVSAs (continued)



––✓✓✓Rx-Connect-Speed26-163

[Subscriber Access]

• The L2TP for Subscriber Access Overview topic in the Junos OS Subscriber Access

Configuration Guide incorrectly states that L2TP is supported only on MX240, MX480,

andMX960 routers. In fact, support for MX80 routers was added in Junos OS Release

12.3. In that release and later releases, the MX80 supports all L2TP features that were

supported on the MX240, MX480, and MX960 routers as of Junos OS Release 11.4.

[Subscriber Access]

• TheMXSeries 3DUniversal Edge Router InterfaceModule Reference does not state that

VLAN demux configurations are not supported on MX Series routers that have any of

the following line cards installed:

• Enhanced Queuing Ethernet Services DPCs (DPCE-X-Q)

• Enhanced Queuing IP Services DPCs (DPCE-R-Q)

The nonsupport includes any configuration stacked on top of a VLAN demux. For

example, although PPPoE is supported, PPPoE over aggregated Ethernet interfaces

isnot supportedwhenoneof thesecards is installed, because this configuration requires

PPPoE to be stacked on a VLAN demux.

• The Configuring Tunnel Interfaces on MX Series Routers topic in the Services 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.

Subscriber Access Management

• In the AAA Service Framework Feature Guide for Subscriber Management, the

parse-direction (Domain Map) statement and the Specifying the Parsing Direction for

DomainNames topic showan incorrectdefault setting for theparse-directionstatement.

The correct default is the left-to-right direction.

• In theSubscriberAccessConfigurationGuide, there is anerror in theExample: Configuring

RADIUS-Based Subscriber Authentication and Accounting topic. In the example, the

profile stanza incorrectly includes the statementauthentication. Thecorrect statement

is authentication-order, as shown in the following sample:

profile isp-bos-metro-fiber-basic {authentication-order radius;

}

[Subscriber Access]



• RADIUS VSAs Not Documented in Subscriber Access Guide (MX Seriesrouters)—Several supported Juniper Networks VSAs are missing from the Junos OS

Release 13.1 Subscriber Access Configuration Guide. The following partial tables show

themissing VSAs.

Table 7: Supported Juniper Networks VSAs


AttributeNumber

Nointeger:

• 0 = disable

• 1 = enable

Whether input statistics are enabled onclient interface.

Ingress-Statistics26-12

Nointeger:

• 0 = disable

• 1 = enable

Whether output statistics are enabledon client interface.

Egress-Statistics26-13

Nostring: bundle-nameThe SSC service bundle.Service-Bundle26-31

Nointeger:

• 0 = do not ignore

• 1 = ignore

State of the Ignore Don’t Fragment (DF)bit on client interface

Ignore-DF-Bit26-70

NostringIndication of user’s connection.Tx-Connect-Speed26-162

NostringIndication of user’s connection.Rx-Connect-Speed26-163

Nointeger: 4-octet

• 1 = dynamic-profile

• 2 = op-script

Indicationof serviceactivation type. Thisis a tagged attribute.

Service-Activate-Type26-173

NostringEnables theRadius server tooverride theclient dynamic profile in theAccess-Accept message.

Client-Profile-Name26-174

Table 8: AAA AccessMessages—Supported RADIUS Attributes and Juniper Networks VSAs

DisconnectRequest

CoARequest

AccessChallenge

AccessReject

AccessAccept


AttributeNumber

––––✓–Ingress-Statistics26-12

––––✓–Egress-Statistics26-13

––––✓–Service-Bundle26-31

––––✓–Ignore-DF-Bit26-70

–––––✓Tx-Connect-Speed26-162



Table 8: AAA AccessMessages—Supported RADIUS Attributes and Juniper NetworksVSAs (continued)

DisconnectRequest

CoARequest

AccessChallenge

AccessReject

AccessAccept


AttributeNumber

–––––✓Rx-Connect-Speed26-163

–✓––✓–Service-Activate-Type26-173

––––✓–Client-Profile-Name26-174

Table9:AAAAccountingMessages—SupportedRADIUSAttributesandJuniperNetworksVSAs



––✓✓✓Tx-Connect-Speed26-162

––✓✓✓Rx-Connect-Speed26-163

[Subscriber Access]

• The L2TP for Subscriber Access Overview topic in the Junos OS Subscriber Access

Configuration Guide incorrectly states that L2TP is supported only on MX240, MX480,

andMX960 routers. In fact, support for MX80 routers was added in Junos OS Release

12.3. In that release and later releases, the MX80 supports all L2TP features that were

supported on the MX240, MX480, and MX960 routers as of Junos OS Release 11.4.

[Subscriber Access]

• TheMXSeries 3DUniversal Edge Router InterfaceModule Reference does not state that

VLAN demux configurations are not supported on MX Series routers that have any of

the following line cards installed:

• Enhanced Queuing Ethernet Services DPCs (DPCE-X-Q)

• Enhanced Queuing IP Services DPCs (DPCE-R-Q)

The nonsupport includes any configuration stacked on top of a VLAN demux. For

example, although PPPoE is supported, PPPoE over aggregated Ethernet interfaces

isnot supportedwhenoneof thesecards is installed, because this configuration requires

PPPoE to be stacked on a VLAN demux.

• The Configuring Tunnel Interfaces on MX Series Routers topic in the Services 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.



Timing and Synchronization

• The Supported Time Synchronization Standards topic fails to mention the following



MIC with SFP, Junos OS substantially supports RFC 4553, Structure-Agnostic Time

Division Multiplexing (TDM) over Packet (SAToP).


VPNs

• The followingguideline regarding the support of LSI traffic statistics onMSeries routers

is missing from the General Limitations on IP-Based Filtering section in the Filtering

Packets in Layer 3 VPNs Based on IP Headers topic:

Label-switched interface (LSI) traffic statisticsarenot supported for IntelligentQueuing

2 (IQ2), Enhanced IQ (IQE), and Enhanced IQ2 (IQ2E) PICs on M Series routers.

[VPNs, Layer 3 VPNs]



on page 3

•




on page 37


on page 73



Upgrade and Downgrade Instructions for Junos OS Release 13.1 for M Series, MX Series, and TSeries Routers

This section discusses the following topics:

• Basic Procedure for Upgrading to Release 13.1 on page 122

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

• Upgrading a Router with Redundant Routing Engines on page 125

• Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS

Release 10.1 on page 125

• Upgrading the Software for a Routing Matrix on page 127

• Upgrading Using ISSU on page 128


Upgrade and Downgrade Instructions for Junos OS Release 13.1 for M Series, MX Series, and T Series Routers

• Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and

NSR on page 128

• Downgrading from Release 13.1 on page 129

Basic Procedure for Upgrading to Release 13.1

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 Junos OS 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 OSSystem Basics Configuration Guide.



http://www.juniper.net/techpubs/en_US/junos/information-products/topic-collections/software-installation-and-upgrade-guide/swconfig-install.pdf

Thedownloadand installationprocess for JunosOSRelease 13.1 is different fromprevious

Junos OS releases.

1. Using aWeb browser, navigate to the All Junos Platforms software download URL on

the Juniper Networks web page:

http://www.juniper.net/support/downloads/

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 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.1R41-domestic-signed.tgz

All other customers use the following command:

user@host> request system software add validate rebootsource/jinstall-13.1R41-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://hostname/pathname

• scp://hostname/pathname (available only for Canada and U.S. version)



http://www.juniper.net/support/downloads/

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

NOTE: Before you upgrade a router that you are using for voice traffic, youshouldmonitor call traffic on each virtual BGF. Confirm that no emergencycalls are active. When you have determined that no emergency calls areactive, you can wait for nonemergency call traffic to drain as a result ofgraceful shutdown, or you can force a shutdown. For detailed informationabouthowtomonitorcall trafficbeforeupgrading, see the JunosOSMultiplaySolutions Guide.

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 about EEOL releases and to review a list of EEOL releases, see

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



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

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



http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/software-installation-and-upgrade/software-installation-and-upgrade.pdf

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

Junos OSMulticast Configuration Guide.



Upgrading the Software for a RoutingMatrix

A routing matrix can comprise a TXMatrix router as the switch-card chassis (SCC) and

T640 LCCs, or a TXMatrix Plus router as the switch-fabric chassis (SFC) and T1600 or

T4000LCCs. By default, when youupgrade software for aTXMatrix router or aTXMatrix

Plus router, thenew image is loadedonto theTXMatrix orTXMatrixPlus router (specified

in the Junos OS CLI by using the scc or sfc option) and distributed to all line-card chassis

(LCC) in the routing matrix (specified in the Junos OS CLI by using the lcc option). To

avoid network disruption during the upgrade, ensure that the following conditions are

met before beginning the upgrade process:

• Aminimumof freedisk spaceandDRAMoneachRoutingEngine.Thesoftwareupgrade

fails on any Routing Enginewithout the required amount of free disk space andDRAM.

To determine the amount of disk space currently available on all Routing Engines 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 SCC, the SFC, and the connected LCCs are all

designated as re0 or re1 in the CLI.

• The backup Routing Engines of the TXMatrix or TX Matrix Plus router (SCC or SFC)

and all connected LCCs are all re1 or are all re0.

• All master Routing Engines in all routers run the same version of Junos OS. This is

necessary for the routing matrix to operate.

• For the TXP-T1600 configuration, youmust upgrade the router to Junos OS Release

9.6R2 or later. A routing matrix in the TXP-T1600 configuration supports 32-bit and

64-bit Junos OS. However, the SFC and LCCmust run either 32-bit Junos OS or 64-bit

Junos OS.

• Starting with Junos OS Release 13.1, a routing matrix with the TXP-T1600-3D,

TXP-T4000-3D, or TXP-Mixed-LCC-3D configuration supports 64-bit Junos OS.

• All master and backup Routing Engines run the same version of Junos OS before the

upgrade procedure begins. Different versions of 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 Junos OS is recommended.

• For a routing matrix with a TXMatrix router, the same Routing Engine model is used

within aTXMatrix router (SCC) andwithin aT640 router (LCC). For example, a routing

matrixwithanSCCusing twoRE-A-2000sandanLCCusing twoRE-1600s is supported.

However, an SCCor an LCCwith twodifferent Routing Enginemodels is not supported.

We suggest that all Routing Engines be the samemodel throughout all routers in the

routingmatrix. Todetermine theRoutingEngine type, use theCLI showchassishardware

| match routing command.

• For a routingmatrixwith a TXMatrix Plus router, both Routing Engines in the SFCmust

be the samemodel number. Each LCCmust contain twoRouting Engines. The Routing

Engines in all LCCsmust be the samemodel number.



For more information about which Routing Engines are supported for the TXMatrix

Plus router, T1600 router, and T4000 router, seeSupportedRouting Engines byChassis.

NOTE: It is considered best practice tomake sure that all master RoutingEngines are re0 and all backup Routing Engines are re1 (or vice versa). For

the purposes of this document, themaster Routing Engine is re0 and the

backup Routing Engine is re1.

To upgrade the software for a routing matrix, perform the following steps:

1. Perform commit synchronization on the SFC.

2. Disable graceful Routing Engine switchover (GRES) on themaster Routing Engine

(re0) and save the configuration change to both Routing Engines.

3. Install the new Junos OS release on the backup Routing Engine (re1) while keeping

the currently running software version on themaster Routing Engine (re0).

4. Load the new Junos OS on the backup Routing Engine andmake sure that the new

software version is running correctly on the backup Routing Engine (re1).

5. Switch mastership to Routing Engine re1 to activate the new software.

For the detailed procedure, see the Upgrading the Software for a Routing Matrix with a TX

MatrixRouteror theUpgrading the JunosOSonaRoutingMatrixwithaTXMatrixPlusRouter.

Upgrading Using 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 Junos OS High Availability Configuration Guide.

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



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.1/topics/task/configuration/tx-matrix-software-upgrade-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/task/configuration/tx-matrix-software-upgrade-solutions.html

http://www.juniper.net/techpubs/en_US/junos13.1/topics/task/configuration/routing-matrix-tx-matrix-plus-upgrading-software-solutions.html

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 can either use the standard procedure with 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.1

To downgrade from Release 13.1 to another supported release, follow the procedure for

upgrading, but replace the 13.1 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 Junos OS Installation and Upgrade Guide.



on page 3

•




on page 37


on page 73





http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pages/software-installation-and-upgrade/software-installation-and-upgrade.pdf

Junos OS Documentation and Release Notes

For a list of related Junos OS documentation, see

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

If the information in the latest release notes differs from the information in the

documentation, follow the Junos OS Release Notes.

To obtain the most current version of all Juniper Networks®technical documentation,

see the product documentation page on the Juniper Networks website at

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

JuniperNetworkssupportsa technicalbookprogramtopublishbooksby JuniperNetworks

engineers and subject matter experts with book publishers around the world. These

books go beyond the technical documentation to explore the nuances of network

architecture, deployment, and administration using the Junos operating system (Junos

OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library,

published in conjunction with O'Reilly Media, explores improving network security,

reliability, and availability using Junos OS configuration techniques. All the books are for

sale at technical bookstores and book outlets around the world. The current list can be

viewed at http://www.juniper.net/books.

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.

• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.


Junos OS Documentation and Release Notes

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

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

http://www.juniper.net/books

mailto:[email protected]

https://www.juniper.net/cgi-bin/docbugreport/

http://www.juniper.net/customers/support/downloads/710059.pdf

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:

https://www.juniper.net/alerts/

• 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/customers/support/

http://www2.juniper.net/kb/

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

http://kb.juniper.net/

http://www.juniper.net/customers/csc/software/

https://www.juniper.net/alerts/

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]

https://www.juniper.net/cgi-bin/docbugreport/

Revision History

15 April 2014—Revision3, Junos OS 13.1 R4 – T Series.

8 April 2014—Revision 2, Junos OS 13.1 R4 – T Series.


21 November 2013—Revision 4, Junos OS 13.1 R3 – T Series.

24 September 2013—Revision 3, Junos OS 13.1 R3 – T Series.



11 July 2013—Revision 3, Junos OS 13.1 R2 – T Series.

26 June 2013—Revision 2, Junos OS 13.1 R2 – T Series.

12 June 2013—Revision 1, Junos OS 13.1 R2 – T Series.


27 March 2013—Revision 2, Junos OS 13.1 R1 – T Series.

19 March 2013—Revision 1, Junos OS 13.1 R1 – T 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.


Requesting Technical Support

junos release notes 13.1

Documents

mx series

junos os release notes

t series routers

junosos release

junos os releases124upgrading

release notesrelease

forthis release

t series core routersnote