This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• Extended cablemanager for EX9214 switches—An extended cable manager is nowavailable for EX9214 switches. The extended cablemanager allows you to route cables
away from the front of the line cards and Switch Fabric modules and provides easier
access to the switch than the standard cable manager. To obtain the extended cable
manager, order the MX960 Enhanced Cable Manager, ECM-MX960. (Note that
installation of the extended cable manager must be done by a Juniper-authorized
technician and that the service cost is in addition to the component cost.) SeeMX960
Cable Manager Description .
Infrastructure
• Support for IPv6 forTACACS+authentication (EX9200)—StartingwithRelease 13.3,Junos OS supports IPv6 along with the existing IPv4 support for user authentication
using TACACS+ servers.
Multicast
• MLD snooping on EX9200 switches—EX9200 switches support MLD snooping.Multicast Listener Discovery (MLD) snooping constrains the flooding of IPv6multicast
traffic on VLANs on a switch. When MLD snooping is enabled on a VLAN, the switch
examinesMLDmessages between hosts andmulticast routers and learnswhich hosts
are interested in receiving traffic for a multicast group. Based on what it learns, the
switch then forwards multicast traffic only to those interfaces in the VLAN that are
connected to interested receivers instead of flooding the traffic to all interfaces. You
configure MLD snooping at either the [edit protocols] hierarchy level or the [edit
routing-instances routing-instance-name protocols] hierarchy level. See Understanding
MLD Snooping.
NetworkManagement andMonitoring
• sFlowtechnologyonEX9200switches—EX9200switchessupportsFlowtechnology,a monitoring technology for high-speed switched or routed networks. The sFlow
monitoring technology randomly samples network packets and sends the samples to
amonitoring station. You can configure sFlow technology on an EX9200 switch to
continuously monitor traffic at wire speed on all interfaces simultaneously. The sFlow
technology is configuredat the[editprotocolssflow]hierarchy level. SeeUnderstanding
How to Use sFlow Technology for Network Monitoring on an EX Series Switch.
OpenFlow
• Support for OpenFlow v1.0—Starting with Junos OS Release 13.3, EX9200 switchessupport OpenFlow v1.0. You use the OpenFlow remote controller to control traffic in
an existing network by adding, deleting, andmodifying flows on switches. You can
configure oneOpenFlow virtual switch and one activeOpenFlow controller at the [edit
protocols openflow] hierarchy level on each device running Junos OS that supports
OpenFlow. See Understanding Support for OpenFlow on Devices Running Junos OS.
• Migration, Upgrade, and Downgrade Instructions on page 15
• Product Compatibility on page 16
Changes in Behavior and Syntax
This section lists the changes in behavior of JunosOS features and changes in the syntax
of JunosOS statements and commands from JunosOSRelease 13.3R4 for the EXSeries.
• Interfaces and Chassis on page 7
• User Interface and Configuration on page 7
Interfaces and Chassis
• On EX9200 switches, the arp-l2-validate command provides a workaround for issues
related to MAC and ARP entries going out of sync in an MC-LAG scenario. Use the
commandtocorrectmismatchesbetweenMACandARPentries related to thenext-hop
interface.
• On EX9200 switches, the following CLI commands have been added to the output of
the request support information CLI command:
• show ethernet-switching interface detail
• show ethernet-switching table
• show spanning-tree bridge detail
• show spanning-tree interface
• show vlans extensive
• show vrrp summary
User Interface and Configuration
• Change in show version command output on EX9200 switches—Beginning in JunosOS Release 13.3, the show version command output includes the new Junos field that
displays the Junos OS version running on the device. This new field is in addition to the
list of installed sub-packages running on the device that also display the Junos OS
version number of those sub-packages. This field provides a consistent means of
identifying the Junos OS version, rather than extracting that information from the list
of installed sub-packages. In the future, the list of sub-packages might not be usable
for identifying the JunosOS version running on the device. This change in outputmight
impact existing scripts that parse information from the show version command.
In Junos OS Release 13.2 and earlier, the show version command does not have the
single Junos field in theoutput thatdisplays the JunosOSversion runningon thedevice.
The only way to determine the Junos OS version running on the device is to review the
list of installed sub-packages.
Junos OS Release 13.3 and Later ReleasesWith the JunosField
Junos OS Release 13.2 and Earlier ReleasesWithout theJunos Field
user@switch> show versionHostname: lab Model: ex9208 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...
user@switch> show versionHostname: lab Model: ex9208 JUNOS Base OS boot [12.3R2.5]JUNOS Base OS Software Suite [12.3R2.5]JUNOS Kernel Software Suite [12.3R2.5]JUNOS Crypto Software Suite [12.3R2.5]...
[See show version.]
• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in theCLI—JunosOS reserves theprefix junos- for the identifiers of configurationsdefinedwithin the junos-defaults configuration group. User-defined identifiers cannot
startwith the string junos-. If you configureduser-defined identifiers using the reserved
prefix through a NETCONF or Junos XML protocol session, the commit would correctly
fail. Prior to Junos OS Release 13.3, if you configured user-defined identifiers through
the CLI using the reserved prefix, the commit would incorrectly succeed. Junos OS
Release 13.3R1 and later releases now exhibit the correct behavior. Configurations that
currently contain the reserved prefix for user-defined identifiers other than
junos-defaults configuration group identifiers will now correctly result in a commit
error in the CLI.
• Configuring regularexpressions(EX9200)—Inall supported JunosOSreleases, regularexpressions can no longer be configured if they require more than 64MB of memory
or more than 256 recursions for parsing.
This change in the behavior of Junos OS is in line with the FreeBSD limit. The change
wasmade in response to a known consumption vulnerability that allows an attacker
to cause a denial of service (resource exhaustion) attack by using regular expressions
containing adjacent repetition operators or adjacent bounded repetitions. Junos OS
uses regular expressions in several placeswithin theCLI. Exploitationof this vulnerability
can cause the Routing Engine to crash, leading to a partial denial of service. Repeated
exploitation can result in an extendedpartial outageof services providedby the routing
• SFP-GE80KCW1470-ET, SFP-GE80KCW1490-ET, SFP-GE80KCW1510-ET,SFP-GE80KCW1530-ET, SFP-GE80KCW1550-ET, SFP-GE80KCW1570-ET,SFP-GE80KCW1590-ET, and SFP-GE80KCW1610-ET (MX Series)—Beginning withJunos OS Release 13.3, these transceivers provide a duplex LC connector and support
operationandmonitoringwith linksup toadistanceof80km.Each transceiver is tuned
to a different transmit wavelength for use in CWDM applications. These transceivers
are supported on the following interfacemodule. Formore information about interface
modules, see the Interface Module Reference for your router.
• Gigabit Ethernet MIC with SFP (model number: MIC-3D-20GE-SFP) in all versions
of MX-MPC1, MX-MPC2, and MX-MPC3—Supported in Junos OS Release 12.3R5,
• Software feature support on theMPC5E— Starting in Junos OS Release 13.3, MPC5E
supports the following key features:
• Basic Layer 2 features and virtual private LAN services (VPLS) functionality
• Class of service (CoS)
• Flexible Queuing option—By using an add-on license, MPC5E supports a limited
number of queues (32,000 queues per slot including ingress and egress)
• Hierarchical QoS
• Intelligent oversubscription services
• Interoperability with existing MPCs and DPCs
• MPLS
• MX Virtual Chassis
The following features are not supported on MPC5E:
• Active flowmonitoring and services
• Subscriber management features
[SeeProtocols andApplications Supported by theMX240,MX480,MX960,MX2010, and
MX2020MPC5E.]
• SoftwarefeaturesupportontheMPC5EQ—Starting in JunosOSRelease 13.3,MPC5EQ
supports 1 million queues per slot on all MX Series routers. All the other software
features supported on MPC5E are also supported on MPC5EQ.
[SeeProtocols andApplications Supported by theMX240,MX480,MX960,MX2010, and
MX2020MPC5E.]
• Support for new 520-gigabit full duplex Modular Port Concentrator (MPC6E) withtwoModular InterfaceCard (MIC) slots onMX2010andMX20203DUniversal EdgeRouters—In Junos OS Release 13.3R3 and later, MX2020 andMX2010 routers supportanewMPC,MPC6E(model number:MX2K-MPC6E).MPC6E is a 100-Gigabit Ethernet
MPC that provides increased density and performance to MX Series routers in
broadband access networks for services such as Layer 3 peering, VPLS and Layer 3
aggregation, and video distribution.
MPC6Eprovides packet-forwarding services that deliver up to 520Gbps of full-duplex
traffic. It has two separate slots forMICs and supports four Packet Forwarding Engines
with a throughput of 130Gbps per Packet Forwarding Engine. It also supports twoMIC
slots asWAN ports that provide physical interface flexibility.
MPC6E supports:
• Forwarding capability of up to 130 Gbps per Packet Forwarding Engine
The following features are not supported on MPC6E:
• Fine-grained queuing and input queuing
• Unified in-service software upgrade (ISSU)
• Active flowmonitoring and services
• Virtual Chassis support
[SeeProtocols andApplications Supported by theMX240,MX480,MX960,MX2010, and
MX2020MPC5E.]
• Support for fixed-configurationMPC onMX240, MX480, MX960, MX2010, andMX2020 routers—MX2020, MX2010, MX960, MX480, and MX240 routers support anewMPC, MPC5E (model number: MPC5E-40G10G). On the MX2010 and MX2020
routers, MPC5E is housed in an adapter card. MPC5E is a fixed-configurationMPCwith
four built-in PICs and does not contain separate slots for Modular Interface Cards
(MICs). MPC5E supports two Packet Forwarding Engines, PFEO and PFE1. PFE0 hosts
PIC0 and PIC2while PFE1 hosts PIC1 and PIC3. A maximum of two PICs can be kept
powered on (PIC0 or PIC2 and PIC1 or PIC3). The other PICs are required to be kept
powered off.
MPC5E supports:
• Flexible queuing option by using an add-on license
• Forwarding capability of up to 130 Gbps per Packet Forwarding Engine
• Intelligent oversubscription services
• Quad small form-factor pluggable plus transceivers (QSFP+) and small form-factor
pluggable plus transceivers (SFP+) for connectivity
• Up to 240 Gbps of full-duplex traffic
• WAN-PHYmode on 10-Gigabit Ethernet Interfaces on a per-port basis
Formore informationabout thesupportedandunsupported JunosOSsoftware features
for this MPC, see Protocols and Applications Supported by theMX240, MX480, MX960,
MX2010, and MX2020 MPC5E.
• Support for new fixed-configuration queuingMPC onMX240, MX480, MX960,MX2010, andMX2020 routers—MX2020, MX2010, MX960, MX480, and MX240routers support a new queuing MPC, MPC5EQ (model number: MPC5EQ-40G10G).
On theMX2010 andMX2020 routers, MPC5EQ is housed in an adapter card. MPC5EQ,
like MPC5E, is a fixed-configuration MPCwith four built-in PICs and does not contain
separate slots for Modular Interface Cards (MICs). MPC5EQ, like MPC5E supports two
• Support for 100 Gigabit-Ethernet OTNMIC onMPC6E (MX2010 andMX2020routers)—Startingwith JunosOSRelease 13.3R3, the 2-port 100-Gigabit EthernetMICwith CFP2 (MIC6-100G-CFP2) is supported on MPC6E. The MIC supports optical
transport network (OTN) features on the 100-Gigabit Ethernet interfaces and also
supports line-rate throughput of 100 Gbps per port.
The following OTN features are supported:
• Transparent transport of 2-port 100-Gigabit Ethernet signals with optical channel
data unit 4 (ODU4) framing for each port
• ITU-standard OTN performancemonitoring and alarmmanagement
• Generic forward error correction (GFEC)
To configure OTN options for this MIC, use the set otn-options statement at the [edit
• Support for MPC5E on SCBE2 (MX Series routers)—Starting with Junos OS Release13.3R3, MPC5E is supported on SCBE2 on MX240, MX480, and MX960 routers.
• Support for enhanced 20-port Gigabit Ethernet MIC (MX5, MX10, MX40, MX80,MX240,MX480,andMX960)—Starting in JunosOSRelease 13.3, anenhanced20-portGigabit EthernetMIC(modelnumberMIC-3D-20GE-SFP-E) is supportedonMXSeries
routers. This enhancedMIC supports up to 20 SFP optical transceiver modules, which
• Multiservices MIC support (MX104)—Starting with Junos OS Release 13.3R2, theMultiservices MIC (MS-MIC-16G) is supported on MX104 3D Universal Edge Routers.
To configure CCC over FRF.16/MFR interfaces, include the following statements under
the [edit interfaces interface-name unit number] hierarchy level:
family ccc {translate-discard-eligible;translate-fecn-and-becn;translate-plp-control-word-de;no-asynchronous-notification;
}
To configure TCC over FRF.15/MLFR, FRF.16/MFR, or MLPPP interfaces, include the
followingconfigurationunder the [edit interfaces interface-nameunitnumber]hierarchy
level:
family tcc {protocols [inet isompls];no-asynchronous-notification;
}
To complete CCC or TCC configurations over the multilink Frame Relay interfaces, you
must also specify the interface name under one of the following hierarchies:
• [edit protocols l2circuit neighbor ip-address] if the switching is done over a Layer 2
circuit.
• [edit protocols connections remote-interface-switch remote-if-sw] if the switching
is done over a remote interface switch.
• [edit protocols connections interface-switch local-if-switch] if the switching is done
using a local switch.
• Support for IPv6 traffic over IPsec tunnels onMS-MICs andMS-MPCs (MXSeries)—Starting with Release 13.3, Junos OS extends IPsec support on MS-MICs andMS-MPCs to IPv6 traffic. IPsec support on MS-MICs and MS-MPCs is limited to the
ESP protocol, and now enables you to configure IPv4 and IPv6 tunnels that can carry
IPv6 as well as IPv4 traffic. To enable IPv6 traffic over an IPsec tunnel, configure an
IPv6 address for the local-gateway statement under the [edit services service-set
• CoS show command enhancements (MX Series)—Starting in Release 13.3, Junos OSextendssupport forCoS showcommandswith theadditionof the showclass-of-service
commands. These commands display subscriber class-of-service interface and
interface-set information.
[See show class-of-service scheduler-hierarchy interface and show class-of-service
scheduler-hierarchy interface-set.]
• Traffic schedulingandshaping support forGRE tunnel interfaceoutputqueues (MXSeries)—Beginning with Junos OS Release 13.3, you canmanage output queuing oftraffic entering GRE tunnel interfaces hosted on MIC or MPC line cards in MX Series
routers. Support for the output-traffic-control-profile configuration statement, which
applies an output traffic scheduling and shaping profile to the interface, is extended
to GRE tunnel physical and logical interfaces. Support for the
output-traffic-control-profile-remaining configuration statement, which applies an
output traffic scheduling and shaping profile for remaining traffic to the interface, is
extended to GRE tunnel physical interfaces.
NOTE: Interface sets (sets of interfaces used to configure hierarchical CoSschedulers on supported Ethernet interfaces) are not supported on GREtunnel interfaces.
[See Configuring Traffic Control Profiles for Shared Scheduling and Shaping.]
• New forwarding-class-accounting statement onMX Series routers—Starting in JunosOS Release 13.3R3, new forwarding class accounting statistics can be enabled at the
[edit interfaces interface-name] and the [edit interfaces interface-name unit
interface-unit-number] hierarchy levels. These statistics replace theneed touse firewall
filters for gathering accounting statistics. Statistics can be gathered and displayed for
IPv4, IPv6, MPLS, Layer2 and Other families in ingress, egress, or both directions.
• Support for CoS hierarchical schedulers onMPC5E (MX240, MX480, MX960,MX2010,andMX2020routers)—Starting in JunosOSRelease 13.3R3, class-of-service(CoS) hierarchical schedulers can be configured on MPC5E interfaces. This feature is
supported on egress only.
You can use hierarchical schedulers to define traffic control profiles, which set the
following CoS parameters on a CoS interface:
• Delay buffer rate
• Excess bandwidth
• Guaranteed rate
• Overhead accounting
• Scheduler map
• Shaping rate
General Routing
• Nonstop active routing support for logical systems (MX Series)—Starting in Junos
OSRelease 13.3, this featureenablesnonstopactive routing support for logical systems
using the nonstop-routing option under the [edit logical-systems logical-system-name
routing-options] hierarchy. As a result of extending nonstop active routing support for
logical systems, the logical-systems argument has been appended in some show
operational commands to allow display of status, process, and event details.
• Nonstopactive routing formultipoint labeldistributionprotocol (MSeries,MXSeries,and T Series)—Starting in Junos OS Release 13.3, this feature enables nonstop active
routing for the multipoint label distribution protocol, using the nonstop-routing option
at the [edit routing-options] hierarchy level. Themultipoint label distribution protocol
state, event, and process details can be viewed using the p2mp-nsr-synchronization
• MXSeries Virtual Chassis support for multichassis link aggregation (MX Seriesrouters with MPCs)—Starting in Junos OS Release 13.3, an MX Series Virtual Chassissupports configuration of multichassis link aggregation (MC-LAG). MC-LAG enables
a device to form a logical link aggregation group interface with two or more other
devices. The MC-LAG devices use the Inter-Chassis Communication Protocol (ICCP)
to exchange control information between twoMC-LAG network devices.
When you configure MC-LAGwith an MX Series Virtual Chassis, the link aggregation
group spans links to two Virtual Chassis configurations. Each Virtual Chassis consists
of two MX Series member routers that form a logical systemmanaged as a single
network element. ICCP exchanges control information between the global master
router (VC-M) of the first Virtual Chassis and the VC-M of the second Virtual Chassis.
NOTE: Internet GroupManagement Protocol (IGMP) snooping is notsupported onMC-LAG interfaces in an MX Series Virtual Chassis.
[See Configuring Multichassis Link Aggregation.]
• TCPauto-merge support in nonstop active routing for short duration hold timers forprotocols (BGP, LDP) (kernel) (M Series, MX Series, and T Series)—Beginning withJunosOSRelease 13.3, TCPauto-merge support in nonstopactive routing for protocols
(BGP, LDP) (kernel) is enabledon theMSeries,MXSeries, andTSeries.Nonstopactive
routing automerge is one of the kernel components of the socket replication. On
switchover, this componentmerges the socket pairs automatically from the secondary
to the primary Routing Engine. Currently, nonstop active routing switchover from
secondary to primary happenswhen rpd issues amerge call for each secondary socket
pair to merge them to a single socket, which can result in a delay. To avoid this delay,
this feature introducesanautomergemodule in thekernel thatdecouples thesecondary
socket merge from rpd and automatically merges secondary sockets on switchover
so that the rpd high priority thread takes advantage of this and generates faster
keep-alive to sustain TCP connections on switchover.
• Nonstop active routing support for BGP addpath (M Series, MX Series, and TSeries)—Beginning in Junos OS Release 13.3, nonstop active routing support for BGPaddpath is available on the M Series, MX Series, and T Series. Nonstop active routing
support is enabled for the BGP addpath feature. After the nonstop active routing
switchover, addpath-enabled BGP sessions do not bounce. The secondary Routing
Engine maintains the addpath advertisement state before the nonstop active routing
• Interchassis high availability provides stateful redundancy (MS-MPC andMS-MICinterface cards onMXSeries routers)—Starting with Release 13.3, Junos OS supportsstateful high availability (HA) to replicate flow states on an activeMS-MPCorMS-MIC
service card to a standby MS-MPC or MS-MIC service card on a different chassis. This
enables the preservation of the state of the existing flows in case of a planned or
unplanned switchover.
Services to be synchronized statefully include:
• Stateful firewall
• NAT (NAPT44 and APP only)
Both IPv4 and IPv6 sessions are synchronized.
Synchronizationoccurs for long-lived flowsasdefinedbyaconfigurable synchronization
threshold.
[See Inter-Chassis High Availability for MS-MIC andMS-MPC.]
• Support for unified in-service software upgrade onMX Series routers with MPC3andMPC4E (MX240, MX480, andMX960)—Starting in Release 13.3, Junos OSsupports unified in-service software upgrade (ISSU) on MX Series routers with MPC3
and MPC4E. Unified ISSU is a process to upgrade the system software with minimal
disruption of transit traffic and no disruption of the control plane. In this process, the
new system software version must be later than the version of the previous system
software. When unified ISSU completes, the new system software state is identical
to that of the system software when the system upgrade is performed through a cold
boot.
• MXSeriesVirtual Chassis support for inline flowmonitoring (MXSeries routerswithMPCs)—Starting in Junos OS Release 13.3R3, you can configure inline flowmonitoring
for anMXSeries Virtual Chassis. Inline flowmonitoring enables you to activelymonitor
the flow of traffic by means of a router participating in the network.
Inline flowmonitoring for an MX Series Virtual Chassis provides the following support:
• Active sampling and exporting of both IPv4 and IPv6 traffic flows
• Sampling traffic flows in both the ingress and egress directions
• Configuration of flow collection on either IPv4 or IPv6 devices
• Use of the IPFIX flow collection template for traffic sampling (both IPv4 and IPv6
export records)
Interfaces and Chassis
• Transmit ESMC SSMquality level from synchronous Ethernetmode (MXSeries)—Starting in Junos OS Release 13.3, when an MX Series router is configured insynchronous Ethernet mode, the ESMC SSM quality level can be transmitted. The setchassis synchronizationmax-transmit-quality-level command sets a thresholdquality level for the entire system.
• Ethernet frame padding with VLAN (DPCs andMPCs running onMX Seriesrouters)—Starting in JunosOSRelease 13.3, DPCs andMPCs onMXSeries routers pad
the Ethernet frame with 68 bytes if the packet is VLAN tagged and the frame length
is less than68bytesandgreater thanor equal to64bytesat theegressof the interface.
• PTP redundancy support for line cards (MX Series andMSeries)—Beginning withJunos OS Release 13.3, line cards on MX Series and M Series routers support slave
redundancy. If multiple slave streams are configured across line cards and the active
slave line card crashes or all of the streams on that line card lose their timing packets,
another slave line card takes over if it has been primed to do so.
• Increased Layer 3 forwarding capabilities forMPCs andMultiservicesDPCs throughFIB localization(MXSeries)—Starting in JunosOSRelease 13.3, forwarding informationbase (FIB) localization characterizes the Packet Forwarding Engines in a router into
two types: FIB-Remote and FIB-Local. FIB-Local Packet Forwarding Engines install all
of the routes from the default route tables into Packet Forwarding Engine forwarding
hardware. FIB-Remote Packet Forwarding Engines create a default (0.0) route that
referencesanexthoporaunilist ofnexthops to indicate theFIB-Local that canperform
full IP table looks-ups for received packets. FIB-Remote Packet Forwarding Engines
forward received packets to the set of FIB-Local Packet Forwarding Engines.
The capacity of MPCs is much higher than that of Multiservices DPCs, so an MPC is
designatedas the localPacketForwardingEngine, andaMultiservicesDPC isdesignated
as the remote Packet Forwarding Engine. The remote Packet Forwarding Engine
forwards all network-bound traffic to the local Packet Forwarding Engine. If multiple
MPCs are designated as local Packet Forwarding Engines, then the Multiservices DPC
load balances the traffic using the unilist of next hops as the default route.
• Support for centralized clocking (MX2020)—Before Junos OS Release 13.3, theMX2020 supported SyncE (Synchronous Ethernet) in distributedmode, where the
clock module on a line card would lock to the SyncE source and distribute frequency
references to the entire chassis. Starting in Junos OS Release 13.3, the MX2020 uses
the centralized Stratum 3 clock module on the control board to lock onto SyncE and
distribute the frequency to the entire chassis. Supported features include:
• Clock monitoring, filtering, and holdover
• Hitless transition from a distributed to centralized clocking mode
• Distribution of the selected chassis clock source to downstream network elements
through supported line interfaces
You can view the centralized clock module information with the show chassis
• Enhancements to commit check processing (M Series andMX Series)—Starting inJunos OS Release 13.3, the processing performance when you issue the commit check
command has been optimized for the following static and dynamic interface types:
The improved performance for commit check enables the overall commit operation to
complete fasterwhennewdemux0,pp0, or si interfacesareadded to theconfiguration.
• Support for ATM virtual connectionmultiplexing and LLC encapsulation (MXSeries)—Starting in Junos OS Release 13.3, ATM virtual connection (VC) multiplexing
and logical link control (LLC) encapsulation are supported on the Channelized
OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP. ATM virtual connection
multiplexing and LLC are the twomethods for identifying the protocol carried in ATM
ATM virtual connection. The protocol type of each PDU is identified by a prefixed IEEE
802.2 LLC header.
[See ATM Support on Circuit Emulation PICs Overview.]
• Support for MPLS-signaled LSPs to use GRE tunnels (MXSeries)—Starting in JunosOS Release 13.3, MPLS label-switched paths (LSPs) can use generic routing
encapsulation(GRE) tunnels to traverse routingareas, autonomoussystems,and ISPs.
Bridging MPLS LSPs over an intervening IP domain is possible without disrupting the
outlying MPLS domain. This feature is supported on the Channelized OC3/STM1
(Multi-Rate) Circuit Emulation MIC with SFP and is defined in the RFC 4023,
Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE).
[See Configuring MPLS-Signaled LSPs to Use GRE Tunnels.]
• Support for SCBE2 (MX240, MX480, andMX960)—Starting in Junos OS Release13.3, the Enhanced SCB—SCBE2—supports the following features:
• Increased fabric bandwidth per slot
• Improved external clock redundancy
• Dynamic multicast replication only
• GRES
The following scenarios are to be noted when you are using an MX Series router with
an SCBE2:
• Youmust configure the set chassis network-services (enhanced-ip |
enhanced-ethernet) configuration command and reboot the router to bring up the
FPCs on the router. However, after the router reboots, the MS DPC, the MX FPC, and
the ADPC are powered off.
• All the FPCs and DPCs in the router are powered off when you reboot the router
without configuring either the enhanced-ip option or the enhanced-ethernet option
at the [edit chassis network-services] hierarchy level.
• Youmust reboot the router when you configure or delete the enhanced-ip option or
the enhanced-ethernet option at the [edit chassis network-services] hierarchy level.
[See Centralized Clocking Overview and Network Services Mode Overview.]
• Support for GPS external clock interface on the SCBE (MX240, MX480, andMX960)—Starting with Junos OS Release 13.3, you can configure the EnhancedSCB—SCBE—external clock interface to a GPS timing source, which enables you to
select a GPS external source as the chassis clock source. You can also configure the
external clock interface tooutput either the selectedchassis clock sourceor a recovered
line clock source with GPS timing signals of 1 MHz, 5 MHz, or 10 MHz with 1 pulse per
second (PPS).
[See Centralized Clocking Overview and Understanding Clock Synchronization onMX
Series Routers.]
• Support for mixed-ratemode (T4000 and TXMatrix Plus with 3D SIBs)—Startingwith Junos OS Release 13.3, dual-rate mode or mixed-rate mode for PF-24XGE-SFPP
allows you to configure a mix of port speeds of 1 Gigabit and 10 Gigabit. However, on
PF-12XGE-SFPP, note that youcanconfigureport speedsof either 1Gigabit or 10Gigabit
when the PIC is in line rate mode.
You can enable mixed-rate-mode and set port speeds with themixed-rate-mode
statement and the speed 1G |10G statement, respectively, at the [edit chassis fpc x pic
y] hierarchy level. You can disable themixed-ratemode by using the delete chassis fpc
x pic ymixed-rate-mode statement.
[See Configuring Mixed-Rate Mode Operation.]
• ExtendedMPC support for per-unit schedulers (MX Series)—Starting in Junos OSRelease 13.3,you can configure per-unit schedulers on the non-queuing 16x10GEMPC,
MPC3E, andMPC4E,meaning you can include the per-unit-scheduler statement at the
[edit interfaces interface name] hierarchy level. When per-unit schedulers are enabled,
you can define dedicated schedulers for the logical interfaces.
Enablingper-unit schedulerson the 16x10GEMPC,MPC3E, andMPC4Eaddsadditional
output to the show interfaces interface name [detail | extensive] command. This
[See Scheduler Maps and Shaping Rate to DLCIs and VLANs.]
• Provider edge link protection for BGP labeled unicast paths (M Series, MX Series,and T Series)—Starting in Junos OS Release 13.3, a precomputed protection path canbe configured in a Layer 3 VPN such that if a BGP labeled-unicast path between an
edge router in oneASand an edge router in another AS goes down, the protection path
(also known as the backup path) between alternate edge routers in the two ASs can
be used. This is useful in carrier-of-carriers deployments, where a carrier can have
multiple labeled-unicast paths to another carrier. In this case, the protection path
avoids disruption of service if one of the labeled-unicast paths goes down.
[See Understanding Provider Edge Link Protection for BGP Labeled Unicast Paths.]
• Redundant logical tunnels (MXSeries)—Beginningwith JunosOSRelease 13.3, whenyouconnect twodevices through logical tunnels, you cancreateandconfiguremultiple
physical logical tunnels and add them to a virtual redundant logical tunnel to provide
redundancy.
• License support to activate ports (MX104)—Starting with Junos OS Release 13.3license support has been extended for activating the ports on MX104 3D Universal
Edge Routers. MX104 routers have four built-in ports. By default, in the absence of any
valid licenses, all four built-in ports are deactivated. The upgrade license model with
the feature IDs is described in Table 1 on page 34.
Table 1: Port LicenseModel for theMX104
FunctionalityFeature NameFeature ID
Ability to activate the first two built-in ports (xe-2/0/0 andxe-2/0/1)
MX104 2X10G Port Activate (0 and 1)F1
Ability to activate the next two built-in ports (xe-2/0/2 andxe-2/0/3)
MX104 2X10G Port Activate (2 and 3)F2
Both features are also provided in a single license key for ease of use. MX104 routers
do not support the graceful license expiry policy.
• Enhanced load-balancing for MIC andMPC interfaces (MX Series)—Starting with
Junos OS Release 13.3, the following load-balancing solutions are supported on
aggregate Ethernet bundles to correct genuine traffic imbalance among themember
• Support for configuring interface alias names—Starting in JunosOSRelease 13.3, youcan configure a textual description of a logical unit on a physical interface to be the
alias of an interface name. Interface aliasing is supported only at the unit level. If you
configure an alias name, the alias name is displayed instead of the interface name in
the output of all show, show interfaces, and other operational mode commands.
Configuring an alias for a logical unit of an interface has no effect on how the interface
on the router or switch operates. To specify an interface alias, you can use the alias
statement at the [edit interfaces interface-name unit logical-unit-number] and [edit
• The request support informationcommand(MXSeries)—Starting in JunosOSRelease13.3, when you enter the request support information command with or without the
brief statement, the output includes the showsystemcommit commandoutput,which
displays the commit history and pending commits.
• Pseudowire logical interfacedeviceMACaddressconfiguration(MXSeries)—Startingin Junos OS Release 13.3, you can configure a MAC address for a pseudowire logical
interface device that is used for subscriber interfaces over point-to-point MPLS
pseudowires. This feature enables you to specify the MAC address of your choice in
situations in which network constraints require the use of an explicit MAC address.
[See Configuring a Pseudowire Subscriber Logical Interface Device.]
• Support for synchronizing the CB of anMX2020 router with external BITS timingsources (MX2020)—Starting in Junos OS Release 13.3, this feature providesbuilding-integrated timing supply (BITS) input and output support to the two external
clock interfaces (ECI) on the Control Board. You can configure the ECIs for both input
and output BITS. In the absence of any configuration, the ECI is inactive.
You can configure the BITS ECI by using the synchronization statement at the [edit
chassis] hierarchy level. You can view the BITS ECI information by using the show
chassis synchronization extensive command.
[See Understanding Clock Synchronization onMX Series Routers.]
• Distribution of Ethernet connectivity fault management sessions (MXSeries)—Starting with Junos OS Release 13.3, connectivity fault management (CFM)sessions operate in distributedmode and can be processed on the Flexible PIC
Concentrator (FPC) on aggregated Ethernet interfaces. As a result, graceful Routing
Engine switchover (GRES) is supported on aggregated Ethernet interfaces. In releases
before Junos OS Release 13.3, CFM sessions operate in centralizedmode and are
processed on the Routing Engine. However, CFM sessions are not supported on
aggregated Ethernet interfaces if the interfaces that form the aggregated Ethernet
bundle are in mixedmode.
CFM sessions are distributed by default. To disable the distribution of CFM sessions
andtooperate incentralizedmode, include theppmno-delegate-processingstatement
at the [edit routing-options ppm] hierarchy level. However, all CFM sessions should
operate in either only distributed or only centralizedmode. Amixed operation of
distributed and centralizedmodes for CFM sessions is not supported.
• Source class accounting (T4000)—Starting with Junos OS Release 13.3R2, sourceclass usage (SCU) accounting is performed at ingress on a T4000 Type 5 FPC.
• SFPP-10G-CT50-ZR (MX Series)—Beginning in Junos OS Release 13.3R3, theSPFF-10G-CT50-ZR tunable transceiver provides a duplex LC connector and supports
the 10GBASE-Z optical interface specification andmonitoring. The transceiver is not
specified as part of the 10-Gigabit Ethernet standard and is instead built according to
• PTP path tracemechanism onMX Series—Starting with Junos OS Release 13.3R4,you can use a path trace mechanism to detect PTP loops in a PTP ring topology over
an IPv4 network. A path trace is the route that aPTPannouncemessage takes through
the network trail of boundary clocks and is tracked through the path trace TLV in the
announcemessage. The path trace sequence contains the clock ID of each boundary
clock that an announcemessage traverses. To view the path trace, use the show ptp
path-trace detail operational mode command.
• Software feature support (MX104)—Starting in Junos OS Release 13.3 support isextended for the following software features on theMX1043DUniversal EdgeRouters:
• IP features—IPv6 Provider Edge (6PE), Access Node Control Protocol (ANCP), DHCP
snooping, DHCP Option-82, Multicast Listener Discovery (MLD), and Domain Name
System (DNS).
• MPLS features—MPLS Transport Profile (MPLS-TP), ATM Single Cell Relay over
MPLS (CRoMPLS) VCMode, Generalized MPLS (GMPLS), and VPNv6.
• New forwarding-class-accountingstatement(MXSeries)—Starting in JunosOSRelease13.3R3, new forwardingclassaccounting statistics canbeenabledat the [edit interfaces
interface-name] and [edit interfaces interface-nameunit interface-unit-number] hierarchy
levels. These statistics replace the need to use firewall filters for gathering accounting
statistics. Statistics can be gathered in ingress, egress, or both directions. Statistics
are displayed for IPv4, IPv6, MPLS, Layer 2, and Other families.
NOTE: If you implement this feature in Release 13.3R3, contact JTAC priorto upgrading to Release 14.1R1 or later.
Layer 2 Features
• Computation of the Layer 2 overhead attribute in interface statistics (TSeries)—Starting in Junos OS Release 13.3, on T Series routers, you can configure anattribute at the PIC level to include the Layer 2 overhead (header and trailer bytes) in
the physical interface and logical interface statistics for both ingress and egress
directions. Both the transit and total statistical information includes the Layer 2
overhead in theoutputof theshowinterfaces interface-namecommandforeachphysical
or logical interface on that PIC.
The ifInOctets and ifOutOctets MIB objects display statistics that include Layer 2
overhead bytes.
MPLS
• Multisegment pseudowire for FEC 129 (M Series, MX Series, and T Series)—JunosOS Release 13.3 and later releases provide support for establishing a dynamic
(PSN). The stitching provider edge (S-PE) devices in anMS-PWare automatically and
dynamically discovered by BGP, and the pseudowire is signaled by LDP using FEC 129.
This arrangement requires minimum provisioning on the S-PEs, thereby reducing the
configuration burden that is associatedwith statically configured Layer 2 circuits while
still using LDP as the underlying signaling protocol.
TheMS-PW feature also provides operation, administration, andmanagement (OAM)
capabilities, such as ping, traceroute, and Bidirectional Forwarding Detection (BFD),
from the terminating PE (T-PE) devices of an MS-PW.
[See Example: Configuring a Multisegment Pseudowire.]
• Control word for BGP VPLS (M320 andMX Series)—For hash calculation, transitrouters must determine the payload. While parsing an MPLS encapsulated packet for
hashing, a transit router can incorrectly calculate an Ethernet payload as an IPv4 or
IPv6 payload if the first nibble of the DAMAC is 0x4 or 0x6, respectively. This false
positive can cause out-of-order packet delivery over a pseudowire. Starting in Junos
OS Release 13.3R3, this issue can be avoided by configuring a BGP VPLS PE router to
• BFD session enhancements (MX Series routers with MPCs or MICs)—Starting inJunosOSRelease 13.3, the followingBFDsessionenhancementshavebeen introduced:
• enhanced-ip option—For BFD over aggregated Ethernet (ae) interfaces, configuringtheenhanced-ipoptionat the [editchassisnetwork-services]hierarchy level increases
the number of BFD sessions. When you activate or deactivate this option, the router
must be rebooted.
• Inlinemode—This enables the router to transmit and receive BFD packets from the
FPChardware. Currently, for BFDover aggregated Ethernet (ae) interfaces, the inline
mode is supported only on MX Series routers with MPCs/MICs that have configured
the inlinemode is supportedbydefault onall theMXSeries routerswithMPCs/MICs.
• ISSUtimernegotiation—During unified ISSU, the timer for BFDsessions is increasedfrom the configured value to 60 seconds.
• Support for BFD over child links of AE or LAG bundle (cross-functional PacketForwarding Engine/kernel/rpd) (M Series, MX Series, and T Series)—Beginning inJunos OS Release 13.3, BFD over child links of an AE or LAG bundle is supported. This
feature provides a Layer 3 BFD liveness detection mechanism for child links of the
Ethernet LAG interface. You can enable BFD to run on individual member links of the
LAG tomonitor the Layer 3 or Layer 2 forwarding capabilities of individual member
links. Thesemicro BFD sessions are independent of each other despite having a single
client that manages the LAG interface. To enable failure detection for aggregated
Ethernet interfaces, include thebfd-liveness-detection statementat the [edit interfaces
• Support for OpenFlow v1.0 (MX80, MX240, MX480, andMX960)—Starting withJunos OS Release 13.3, the MX80, MX240, MX480, and MX960 routers support
OpenFlow v1.0. OpenFlow enables you to control traffic in an existing network using
a remote controller by adding, deleting, andmodifying flows on a switch. You can
configure oneOpenFlow virtual switch and one activeOpenFlow controller at the [edit
protocols openflow] hierarchy level on each device running Junos OS that supports
OpenFlow. On MX Series routers that support OpenFlow, you can also direct traffic
fromOpenFlow networks over MPLS networks by using logical tunnel interfaces and
MPLS LSP tunnel cross-connects.
[SeeOpenFlow Feature Guide.]
Platform and Infrastructure
• VirtualRouteReflector(VRR)—Starting in JunosOSRelease 13.3R3, youcan implementroute reflector capabilityusingageneralpurposevirtualmachineona64-bit Intel-based
blade server or appliance. Benefits of the VRR are:
• Improved scalability (depending on the server core hardware use
• Scalability of the BGP network with lower cost using VRR at multiple locations in
the network
• Fast andmore flexible deployment using Intel servers rather than router hardware
• Space savings through elimination of router hardware
Port Security
• Static ARPwithmulticast MAC address for an IRB interface—Starting in Junos OSRelease 13.3, you can configure a static ARP entry with a multicast MAC address for
an IRB interface that acts as the gateway to the network load balancing (NLB) servers.
Earlier, the NLB servers dropped packets with a unicast IP address and amulticast
MACaddress. JunosOS 13.3 supports the configurationof a staticARPwith amulticast
MAC address.
To configure a static ARP entry with a multicast MAC address for an IRB interface,
configure the ARP entry at the [edit interfaces irb unit logical-unit-number family inet
• Using a firewall filter to prevent or allow datagram fragmentation (MXSeries)—Starting in Junos OS Release 13.3, you can define a firewall filter term to
prevent or allow datagram fragmentation by setting or clearing the Don’t Fragment
flag in the IPv4 header of packets that are matched by the filter. Specify the desired
action at the [edit firewall family inet filter filter-name term term-name then action]
hierarchy level.
• To prevent fragmentation of the IP datagram, include the dont-fragment set action
in a term to set the dont-fragment bit to one.
• To allow fragmentation of the IP datagram, include the dont-fragment clear action
in a term to clear the dont-fragment bit to zero.
[See Configuring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentation and
Firewall Filter Nonterminating Actions.]
• Newfirewall filtergre-keyfieldmatchcondition—Starting in JunosOSRelease 13.3R3,there is a new gre-key match condition at the [edit firewall family inet filter filter-name
term term-name from] hierarchy level. The gre-key match condition allows a user to
match against the gre key field which is an optional field in gre encapsulated packets.
The key can bematched as a single key value and or a range of key values.
• Support for consistent load balancing for ECMP groups (MX Series routers withMPCs)—Starting in Junos OS Release 13.3, effective in Junos OS Release 13.3R3, onMX Series 3D Universal Edge Routers with modular port concentrators (MPCs) only,
you can prevent the reordering of flows to active paths in an ECMP group when one or
more paths fail. Only flows that are inactive are redirected. This feature applies only
to Layer 3 adjacencies learned through external BGP connections. It overrides the
default behavior of disrupting all existing, including active, TCP connections when an
active path fails. Include the consistent-hash statement at the [edit policy-options
policy-statement policy-statement-name then load-balance] hierarchy level. Youmust
also configure a global per-packet load-balancing policy.
[See Actions in Routing Policy Terms. ]
• New fast-lookup-filter statementonMX240,MX480,MX960,MX2010andMX2020routers with MPC5E, MPC5EQ andMPC6EMPCs and compatible MICs—Starting inJunos OS Release 13.3R3, the fast-lookup-filter option is available at the [edit firewall
family (inet | inet6) filter filter-name] hierarchy level. This allows for hardware assist
from compatible MPCs in the firewall filter lookup. There are 4096 hardware filters
available for thispurpose, eachofwhichcansupport up to255 terms.Within the firewall
filters and their terms, ranges, prefix lists, and the except keyword are all supported.
Only the inet and inet6 protocol families are supported.
• Newaction settings for firewall filter termwhen next-interface is down—In previousversions of JunosOS, if the then clause of a firewall filter termwas set to next-interface
and that next interface went down, there would be traffic loss because the default
action is to drop the packet.
Starting in Junos OS Release 13.3R3, the actions accept and next term are available at
the [edit firewall family inet filter filter-name term term-name then next-interface
interface-name] hierarchy level. There is no new configuration option available if the
firewall filter term action is set to next-ip, meaning that if the next-ip is down, traffic is
still dropped.
The action configured at this level only becomes active if the next-interface is down
and the ARP on the interface is cleared. If not configured, the default action is to drop
the packet.
Routing Protocols
• Support forBMPversion3—Starting in JunosOSRelease 13.3, BGPmonitoringprotocol(BMP)version3 is supported.BMPallowsa remotedevice (theBMPstation) tomonitor
BGP as it is running on a router or group of routers. BMP version 3 includes substantial
additional functionality versusversion 1. TheBMPversion3configuration is incompatible
with the old version. If you are running BMP version 1 on your Juniper Networks devices,
be sure to update your BMP configurationwhen you upgrade to JunosOSRelease 13.3.
[See Configuring BGPMonitoring Protocol Version 3.]
• Support for consistent load balancing for ECMP groups (MX Series routers withMPCs)—Effective in JunosOSRelease 13.3R3, onMXSeries 3DUniversal EdgeRouterswithmodular port concentrators (MPCs) only, you can prevent the reordering of flows
to active paths in an ECMP group when one or more paths fail. Only flows that are
inactive are redirected. This feature applies only to Layer 3 adjacencies learned through
external BGP connections. It overrides the default behavior of disrupting all existing,
includingactive, TCPconnectionswhenanactivepath fails. Include the consistent-hash
statement at the [edit policy-options policy-statement policy-statement-name then
load-balance] hierarchy level. Youmust also configure a global per-packet
load-balancing policy.
[See Actions in Routing Policy Terms. ]
• Recursive DNS server ICMPv6 router advertisement option support (M Series, MXSeries, and T Series)—Beginning with Junos OS Release 13.3R4, you can configure amaximum of three recursive DNS server addresses and their respective lifetimes via
static configuration at interface level for IPv6 hosts. Previously, rpd supported only
link-local address information, prefix information, and the link MTU. The router
advertisement-based DNS configuration is useful in networks where an IPv6 host’s
address is auto-configured through an IPv6 stateless address and where there is no
DHCPv6 infrastructure available.
Toconfigure the recursiveDNSserveraddress, include thedns-server-addressstatement
at the [edit protocols router-advertisement interface interface-name] hierarchy level.
• EnablingLayer2ProtocolTunneling(L2PT)support forVLANSpanningTreeProtocol(VSTP) and per-VSTP (MX Series routers with MPC/MICs)—Starting in Junos OS
Release 13.3, this feature enables L2PT support for VSTP/PVSTP.
[See layer2-control.]
You can also enable rewriting of the MAC address for an interface using the
enable-all-ifl option.
[Seemac-rewrite.]
• Chainedcompositenexthops(MXSeriesandTSeries)—Starting in JunosOSRelease13.3, the support of chained composite next hops for directly connected provider edge
To enable chained composite next hops on a T4000 router, the chassis must be
configured to use the enhanced-mode option in network services mode.
• Data plane inline support added for 6rd and 6to4 tunnels connecting IPv6 clientsto IPv4 networks onMX Series routers with MPC line cards—Starting with Release13.3R3, Junos OS supports inline 6rd and 6to4 on Modular Port Concentrator (MPC)
line cards with Trio chipsets, saving customers the cost of using MS-DPCs for the
required tunneling, encapsulation, and decapsulation processes. Anycast is supported
for 6to4 (next-hop service interfaces only). Hairpinning is also supported for traffic
between 6rd domains.
There are no CLI changes for 6rd and 6to4 configurations. To implement the inline
functionality, configure service interfaces on theMPC card as inline services interfaces
(si- ) rather than as MultiServices (ms-) interfaces.
Two new operational commands have been added: show services inline softwire
statistics and clear services inline softwire statistics
• IPsec invalid SPI notification (MX Series, T Series)—Starting in Junos OS release13.3R4, you can enable automatic recovery when peers in a security association (SA)
become unsynchronized. When peers become unsynchronized, this can cause the
transmission of packets with invalid security parameter index (SPI) values and the
dropping of those packets by the receiving peer. You can enable automatic recovery
by using the new respond-bad-spi max-responses configuration statement, which
appears under the hierarchy level [edit services ipsec-vpn ike policy]. This statement
results in a resynchronization of the SAs.
The max-responses value has a default of 5 and a range of 1 through 30.
• IPsec InvalidSPINotification(MXSeriesandT-Series)—Starting in JunosOSRelease13.3R4, you can enable automatic recovery when peers in a security association (SA)
become unsynchronized. When peers become unsynchronized, this can cause the
transmission of packets with invalid security parameter index (SPI) values and the
dropping of those packets by the receiving peer. You can enable automatic recovery
by using the new respond-bad-spi max-responses configuration statement, which
appears under the [edit services ipsec-vpn ike policy] hierarchy level. This statement
results in a resynchronization of the SAs.
The max-responses value has a default of 5 and a range of 1 through 30.
Software Installation and Upgrade
• Support for autoinstallation of satellite devices in a JNU group—In a Junos NodeUnifier (JNU) topology that contains anMX Series router as a controller that manages
satellite devices, such as EX Series Ethernet Switches, QFX Series devices, and ACX
Series Universal Access Routers, the autoinstallation functionality is supported for the
satellite devices. Starting in Junos OS Release 13.3, JNU has an autoinstallation
mechanism that enables a satellite device to configure itself out-of-the-box with no
manual intervention, using the configuration available either on the network or locally
through a removable media, or using a combination of both. This autoinstallation
method is also called the zero-touch facility.
A JNU factory default file, jnu-factory.conf, is present in the /etc/config/ directory and
contains the configuration to perform autoinstallation on satellite devices. The
zero-touch configuration can be disabled by including the delete-after-commit
statement at the [edit system autoinstallation] hierarchy level and committing the
configuration.
[See Autoinstallation of Satellite Devices in a Junos Node Unifier Group and Configuring
Autoinstallation on JNU Satellite Devices.]
Subscriber Management and Services
• Pseudowire subscriber logical interfacesMPCsupport—Starting in JunosOSRelease13.3, pseudowire subscriber logical interfaces are supported on MPCs with Ethernet
MICs only.
• Service packet counting (MX Series)—Starting in Junos OS Release 13.3, you canconfigure the counters that subscriber management uses when capturing volume
statistics for subscribers on a per-service session basis.
packet processing events that occur after the event.
• Deferred counters are not incremented until the packet is queued for transmission,
and therefore include theentirepacketprocessing.Deferredcountersprovideamore
accurate packet count than inline counters, and are more useful for subscriber
accounting and billing.
NOTE: Fast update filters do not support deferred counters.
[See Configuring Service Packet Counting.]
• RADIUS logical line identifier (MX Series)—Starting in Junos OS Release 13.3, serviceproviders can use a virtual port feature, known as the logical line ID (LLID), tomaintain
a reliable and up-to-date customer database for those subscribers whomove from
one physical line to another. The LLID, which is based on the subscriber's user name
and circuit ID, is mapped to the subscriber's physical line. When the subscriber moves
to a different physical line, the service provider database is updated to map the LLID
to the new physical line. Subscriber management supports the LLID feature for PPP
subscribers over PPPoE, PPPoA, and LAC.
[See RADIUS Logical Line Identifier (LLID) Overview.]
• Configurable timers for DHCPv6 address-assignment pools (MX Series)—Startingin Junos OS Release 13.3, subscriber management on MX Series routers supports
configurable timers for address-assignment pools that are used by a DHCPv6 local
server. In addition to the previously supportedmaximum-lease-time timer, you can
configure the valid-lifetime and preferred-lifetime timers to manage address leases
provided by address-assignment pools. You can also configure the renew (T1) and
rebind(T2) times thatsubscribermanagementuses toextendthe lifetimesofaddresses
obtained from an address-assignment pool.
[See DHCPv6 Lease Timers.]
• DHCP statements and options (MX Series)—Starting in Junos OS Release 13.3, youcan use the following statements and options for DHCP subscriber management
for the DHCP auto logout feature when there are duplicate clients.
• delay-authentication—New statement that conserves managed resources on the
router by delaying subscriber authentication until the DHCP request processing
phase.
• server-response-time—New statement that configures the timeframe during which
the router monitors DHCP server responsiveness. The router generates a system log
message when the DHCP server does not respond to relayed packets during the
specified time.
• option hex-string—New option that enables the use of the hex-string option type for
user-defined DHCP attribute options that are added to client packets.
• duplicate-clients-in-subnet—New statement that configures how the router
distinguishes between duplicate clients in the same subnet. This replaces the
duplicate-clients-on-interface statement, which is now obsolete.
[See client-discover-match, delay-authentication, server-response-time, option, and
duplicate-clients-in-subnet.]
• Support for agent circuit identifier filtering in PPPoE subscriber session lockout(M120, M320, andMX Series)—Starting in Junos OS Release 13.3, extend PPPoEsubscriber session lockout has been extended to support identification and filtering of
configurable time period. ACI-based PPPoE subscriber session lockout is useful for
configurations such as PPPoE interworking in which MAC source addresses are not
unique on the PPPoE underlying interface.
ToconfigureACI-basedPPPoEsubscriber session lockout, use theshort-cycle-protection
statement with the filter aci option. To clear an ACI-based lockout condition, issue the
clear pppoe lockout command with the aci option.
[See PPPoE Subscriber Session Lockout Overview.]
• Subscriber management and services feature parity (MX80)—Starting in Junos OSRelease 13.3, the MX80 supports all subscriber management and services features
that are supported by the MX240, MX480, and MX960 routers. Previously, the MX80
router matched feature support for these routers as of Junos OS Release 11.4.
[See Protocols and Applications Supported by MX5, MX10, MX40, andMX80 Routers.]
• Subscriber management and services feature and scaling parity (MX2010 andMX2020)—Starting in Junos OS Release 13.3, the MX2010 and the MX2020 supportall subscriber management and services features that are supported by the MX240,
MX480, and MX960 routers. In addition, the scaling and performance values for the
MX2010 and the MX2020match those of MX960 routers.
[See Protocols and Applications Supported by MX240, MX480, MX960, MX2010, and
andMX2020 EnhancedMPCs (MPCEs), Protocols and Applications Supported by the
MX240, MX480, MX960, MX2010, andMX2020MPC3E, and Protocols and Applications
Supported by the MX240, MX480, MX960, MX2010, andMX2020MPC4Es.]
• Per-subscriber support for multiple instances of the same service with differentparameters (MX Series routers with MPCs or MICs)—Starting In Junos OS Release13.3, a subscriber can havemultiple instances of the same service, provided that each
service instance has a different set of parameters. In earlier Junos OS releases, each
subscriber was limited to only a single instance of each service.
You can configure a specific service instance for a particular subscriber by specifying
a service name and unique service parameters for that instance. Each service instance
is uniquely identified by the combination of its service name and service parameters.
Use the request network-access aaa subscriber delete command to deactivate all
instances of a subscriber service by specifying only the service name, or to deactivate
a specific instance of a service by specifying both the service nameand its parameters.
In earlier Junos OS releases, you deactivated a service by specifying only its service
name, but not its service parameters.
[See Subscriber Services with Multiple Instances Overview.]
• RADIUS accountingmessages for dual-stack subscribers (MX Series)—Starting inJunos OS Release 13.3, when an IPv6 address is assigned using DHCPv6, the RADIUS
interimaccountingmessage includes theassigned IPv6address. If thedelegatedprefix
is provided to the client using DHCPv6-PD, the RADIUS interim accounting message
includes the delegated prefix (IA_PD, such as /56). The
[See RADIUS Accounting Messages for Dual-Stack Subscribers.]
• Support for IPv6 for TACACS+ authentication (MSeries, MX Series, and T Series)—StartingwithRelease 13.3, JunosOSsupports IPv6alongwith theexisting IPv4 support
for user authentication using TACACS+ servers.
• Configurable L2TP receive window size (MX Series)—Starting in Junos OS Release13.3, the new rx-window-size statement at the [edit services l2tp tunnel] hierarchy level
enables you to specify the size of the receive window in the range 4 through 128 on an
L2TP LAC or LNS. The default value is 4. The ReceiveWindow Size AVP (Attribute
Type 10) is not sent in the SCCRQmessage when the default value is configured on a
LAC or in the SCCRPmessage when configured on an LNS.
[See Setting the L2TP ReceiveWindow Size.]
• Clearing ANCP statistics (MX Series)—Starting in Junos OS Release 13.3, you canclear all ANCPstatisticswith the clearancpstatistics command.Youcanclear statistics
for a particular neighbor identified by the neighbor’s IP address with the clear ancp
statistics ip-address ip-address command. You can clear statistics for a particular
neighbor identified by the neighbor’s IP address with the clear ancp statistics
system-namemac-address command.
[See Clearing and Verifying ANCP Statistics.]
• ANCP agent support for nonzero partition IDs (MX Series)—Starting in Junos OSRelease 13.3, the ANCP agent on the router can form adjacencies with multiple logical
partitions on a neighbor when you enable the agent to learn partition IDs during
adjacency negotiation with the neighbor. If the agent receives a SYNmessage from
the neighbor within a configurable period, the agent learns the partition IDs and can
form adjacencies with the partitions. The agent can form an adjacency only with the
neighbor if the SYN is not receivedwithin the period, the partition ID is zero, or learning
is not enabled.
[See Configuring the ANCP Agent to Learn ANCP Partition IDs.]
• Dynamic protocol version detection for ANCP (MX Series)—Starting in Junos OSRelease 13.3, when an ANCP neighbor opens adjacency negotiations, it indicates the
highest version of ANCP that it supports. ANCP neighborsmust be able to identify the
supported versions because ANCP Version 1, defined in RFC 6320, Protocol for Access
Node Control Mechanism in Broadband Networks, is not interoperable with the earlier
version based on GSMPv3.
During negotiation, the receiving neighbor returns the value sent by the other neighbor
if it supports that version, or drops the message if it does not. You can still configure
the router to operate in pre-ietf mode for interoperability with neighbors that support
only GMSPv2.
[See ANCP Topology Discovery and Traffic Reporting Overview.]
• Support forANCPgeneric responsemessagesandresultcodes(MXSeries)—Startingin Junos OS Release 13.3, the ANCP agent supports receipt of generic response
messages. Upon receipt, the router generates a system log, increments the generic
messagecounters,and increments the resultcodecounters.Generic responsemessages
(GRMs) are typically sent instead of specific responsemessageswhen no information
needs to be sent other than a result of success or failure. When themessage reports
a failure, it must include one of eight result codes to indicate the cause. A GRM can
also be sent independent of a request when the failure causes the adjacency to be
shut down.
[See ANCP Topology Discovery and Traffic Reporting Overview.]
• Support for sending and receiving the ANCP Status-Info TLV (MX Series)—Startingin Junos OS Release 13.3, the Status-Info TLV supplements the generic response
message result codes and provides information about a warning or error condition.
Although usually included in generic responsemessages, the TLV can also be included
inotherANCPmessage types.TheStatus-InfoTLVmustbe included ingeneric response
messages when the result code indicates a port is down, a port does not exist, a
mandatory TLV is missing, or a TLV is invalid.
[See ANCP Topology Discovery and Traffic Reporting Overview.]
• DNS address assignment in DHCPv6 IA_NA and IA_PD environments (MXSeries)—Starting in Junos OS Release 12.3R3 and Release 13.3 (but not in Releases13.1 and 13.2), the DHCPv6 local server returns the DNS server address (DHCPv6
attribute 23) as a global DHCPv6 option, rather than as an IA_NA or IA_PD suboption.
DHCPv6 returns theDNSserveraddress that is specified in the IA_PDor IA_NApools—if
both address pools are requested, DHCPv6 returns the address specified in the IA_PD
pool only, and ignores any DNS address in the IA_NA pool.
In releases earlier than 12.3R3, and in Releases 13.1 and 13.2, DHCPv6 returns the DNS
server address as a suboption inside the respective DHCPv6 IA_NA or IA_PD header.
You can use themulti-address-embedded-option-response statement at the [edit
systemservicesdhcp-local-serverdhcpv6overrides]hierarchy level to revert to theprior
behavior. However, returning the DNS server address as a suboption can create
interoperability issues for some CPE equipment that cannot recognize the suboption
information.
[See DHCPv6 Options in a DHCPv6Multiple Address Environment.]
• Support for filtering trace results by subscribers for AAA, L2TP, and PPP (MXSeries)—Starting in Junos OS Release 13.3, you can filter trace results for someprocesses by subscriber. The reduced set of results simplifies troubleshooting in a
scaled environment. Specify the useruser@domain option at the appropriate hierarchy
level:
• AAA (authd)—[edit system processes general-authentication-service traceoptions
Traces that have insufficient information to determine the subscriber username are
automatically excluded from the results.
• Overriding the preferred source address as the source address of NeighborSolicitation/Neighbor Advertisement (NS/NA) on unnumbered interfaces (MXSeries)—By default, if a preferred source address is configured on an unnumberedinterface, thatpreferredaddress is usedas the sourceaddressofNS/NA. If nopreferred
sourceaddress is configured, the routerusesasuitableaddressbasedon thedestination
address scope. Starting in Junos OS Release 13.3, you can configure the router to
override the default configuration of using the preferred source address for NS/NA.
The router ignores thepreferred sourceaddressandusesanappropriateaddressbased
on the destination address scope.
• DHCPv6 local server and relay agent usernameandoption 37 (MXSeries)—Startingin Junos OS Releases 12.3R7, 13.2R4, 13.3R2, the router supports the generation of an
ASCII versionof theauthenticationusername.WhenyouconfigureDHCPv6 local server
or relay agent to concatenate the authentication usernamewith the Agent Remote-ID
option 37, the router uses only the remote-id portion of option 37 and ignores the
enterprise number.
The router no longer supports the enterprise-id and remote-id options for the
relay-agent–remote-id statement.
• Subscribermanagement and services feature and scaling parity (MX104)—Startingin Junos OS Release 13.3R3, the MX104 router supports all subscriber management
and services features that are supported by the MX80 router. In addition, the scaling
and performance values for the MX104 router match those of the MX80 router.
[See Protocols and Applications Supported by MX5, MX10, MX40, andMX80 Routers.]
exchanging DHCPmessages between a DHCP server and DHCP clients that reside in
different virtual routing instances (VRFs). The DHCP cross-VRFmessage exchange
uses the DHCP relay agent to ensure that there is no direct routing between the client
VRF and the DHCP server VRF.
To exchange DHCPmessages between the two VRFs, you configure both the server
side and the client side of the DHCP relay to permit traffic based on the Agent Circuit
ID (DHCP option 82 suboption 1) in DHCPv4 packets and the Relay Agent Interface-ID
(DHCPv6 option 18) in DHCPv6 packets.
• Subscriber management and services feature and scaling parity (MX2010 andMX2020)—Starting in Junos OS Release 13.3, the MX2010 and the MX2020 supportall subscriber management and services features that are supported by the MX240,
MX480, and MX960 routers. In addition, the scaling and performance values for the
MX2010 and the MX2020match those of MX960 routers.
• Enhancedmulticast VPNs traceoptions statement (M Series, MX Series, and TSeries)—Starting in JunosOSRelease 13.3, themulticastVPNs traceoptions statementhas been enhanced starting in Junos OS Release 13.3. This statement can now be
configured at the [edit protocolsmpvn] hierarchy level. In addition, the following
traceoption flags have been added: cmcast-join, inter-as-ad, intra-as-ad, leaf-ad,
mdt-safi-ad, source-active, spmsi-ad, tunnel, and umh.
[See Tracing MBGPMVPN Traffic and Operations.]
• Enhanced egress protection in Layer 3 VPNs (M Series, MX Series, and TSeries)—Starting in Junos OS Release 13.3, enhanced point-of-local-repair (PLR)functionality is available, in which the PLR reroutes service traffic during an egress
failure. As part of this enhancement, the PLR router no longer needs to be directly
connected to the protector router. Previously, if the PLR was not directly connected
to the protector router, the loop-free alternate route did not find the backup path to
the protector. A new configuration statement, advertise-mode, enables you to set the
method for the interior gateway protocol (IGP) to advertise egress protection
availability.
[See Configuring Layer 3 VPN Egress Protection with RSVP and LDP.]
• Control word for BGP VPLS (M320 andMX Series)—For hash calculation, transitrouters must determine the payload. While parsing an MPLS encapsulated packet for
hashing, a transit router can incorrectly calculate an Ethernet payload as an IPv4 or
IPv6 payload if the first nibble of the DAMAC is 0x4 or 0x6, respectively. This false
positive can cause out-of-order packet delivery over a pseudowire. Starting in Junos
OS Release 13.3R3, this issue can be avoided by configuring a BGP VPLS PE router to
request that other BGP VPLS PE routers insert a control word between the label stack
and the MPLS payload.
• Loop prevention in VPLS network due toMACmoves (MX Series)—Starting with
Junos OS Release 13.3R3, the base learning interface approach and the statistical
approach can be used to prevent a loop in a VPLS network by disabling the suspect
customer facing interface that is connected to the loop. Some virtual MACs can
genuinely move between different interfaces and such MACs can be configured to
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
IPv6
• Starting with Junos OS Release 11.4R11, interim-logging is supported with NAT64 on
microkernel (MS-DPC) platforms. The configuration statement
pba-interim-logging-interval under the [interfaces services-options] hierarchy level
enables the feature for NAT64.
Interfaces and Chassis
• Validation of deactivated inline services MLPPP bundle interfaces—Starting withJunos OS Release 13.3, if you attempt to delete or deactivate a static inline service (si)
MLPPPbundle interface that is still referencedby amember link interface,which could
be PPPoE (pp0) or si logical interfaces, and commit the configuration, the commit
operation fails. Youmust reactivate such MLPPP bundle interface before committing
the settings. Alternatively, youmust ensure that member links do not refer a static
and reactivation of an MLPPP bundle is not applicable for interfaces other than si-
interfaces, such as link services IQ (lsq-) and virtual LSQ redundancy (rlsq-) interfaces.
[See Understanding MLPPP Bundles and Link Fragmentation and Interleaving (LFI) on
Serial Links.]
• Changes to DDoS protection policers for PIM and PIMv6 (MX Series with MPCs,T4000with FPC5)—Starting in Junos OS Release 13.3R2, the default values forbandwidth and burst limits have been reduced for PIM and PIMv6 aggregate policers
to prevent starvation of OSPF and other protocols in the presence of high-rate PIM
activity.
Old ValueNew ValuePolicer Limit
20,0008000Bandwidth (pps)
20,00016,000Burst (pps)
To see thedefault andmodified values for DDoSprotection packet-typepolicers, issue
one of the following commands:
• show ddos-protection protocols parameters brief—Displays all packet-type policers.
• show ddos-protection protocols protocol-group parameters brief—Displays only
packet-type policers with the specified protocol group.
An asterisk (*) indicates that a value has beenmodified from the default.
• Changes to distributed denial of service statement and command syntax—Startingin Junos OS Release 13.3R2, the protocol group and packet type syntax has changed
for the protocols statement at the [edit system ddos-protection] hierarchy level and
for the various show ddos-protection protocols commands.
The filter-v4and filter-v6packet typeshavebeenmoved fromtheunclassifiedprotocol
• Deleting PTP clock client (MX104)—Starting with Junos OS Release 13.2, on MX104routers, when you toggle from a secure slave to an automatic slave or vice versa in the
configuration of a Precision Timing Protocol (PTP) boundary clock, youmust first
delete the existing PTP clock client or slave clock settings and then commit the
configuration. You can delete the existing PTP clock client or slave clock settings by
using the delete clock-client ip-address local-ip-address local-ip-address statement at
the [edit protocols ptpmaster interface interface-name unicast-mode] hierarchy level.
You can then addnewclock client configuration by using the set clock-client ip-address
local-ip-address local-ip-address statement at the [edit protocols ptpmaster interface
interface-name unicast-mode] hierarchy level and committing the configuration.
However, if you attempt to delete the existing PTP clock client and add the new clock
client before committing the configuration, the PTP slave clock remains in the free-run
state and does not operate in the auto-select state (to select the best clock source).
This behavior is expected when PTP client or slave settings are modified.
• Preventing the filtering of packets by ARP policers (MX Series routers)—Beginningin Junos OS Release 13.3R3, you can configure the router to disable the processing of
the specified ARP policers on the received ARP packets. Disabling ARP policers can
cause denial-of-service (DoS) attacks on the system. Due to this possibility, we
recommend that you exercise caution while disabling ARP policers. To prevent the
processing of ARPpolicers on the arriving ARPpackets, include the disable-arp-policer
statement at the [edit interfaces interface-name unit logical-unit-number family inet
policer] or the [edit logical-systems logical-system-name interfaces interface-name unit
logical-unit-number family inetpolicer]hierarchy level. Youcanconfigure this statement
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
only for interfaces with inet address families and on MX Series routers with MPCs.
When you disable ARP policers per interface, the packets are continued to be policed
by the distributed DoS (DDoS) ARP policer. Themaximum rate of is 10000 pps per
FPC.
[See Applying Policers.]
Management
• Restrictions forcryptoalgorithmsforFIPS inOpenSSH—Starting in JunosOSRelease13.3, the following options are not allowed on systems operating in FIPSmode:
[edit system services ssh]set key-exchange <algorithm>
Not allowed: group-exchange-sha1, dh-group14-sha1, and dh-group1-sha1.
[edit system services]set hostkey-algorithm <algorithm | no-algorithm>
Not allowed: ssh-dss and ssh-rsa.
Prior to Junos OS Release 13.3, the options were available but should have been
disallowed.
MPLS
• Enhanced support for GRE interfaces for GMPLS (MX Series)—Starting in Junos OSRelease 12.3R7, on GRE interfaces for Generalized MPLS control channels, you can
enable the inner IP header’s ToSbits to be copied to theouter IP packet header. Include
the copy-tos-to-outer-ip-header statement at the [edit interfaces gre unit
logical-unit-number] hierarchy level. Previously, the copy-tos-to-outer-ip-header
statement was supported for GRE tunnel interfaces only.
[See copy-tos-to-outer-ip-header.]
• Enhanced transit LSP statistics collection—Starting in Junos OS Release 13.3R4,RSVP no longer periodically polls for transit LSP statistics. This change does not affect
the showmpls lsp statistics command or automatic bandwidth operations for ingress
LSPs. To enable the polling and display of transit LSP statistics, include the
transit-statistics-polling statement at the [edit protocolsmpls statistics] hierarchy
level. You cannot enable transit LSP statistics collection if MPLS statistics collection
is disabledwith theno-transit-statistics statementat the [editprotocolsmplsstatistics]
hierarchy level.
• In Junos OS releases prior to 13.3, you can configure both fast reroute and node and
link protection on the same LSP. Beginning in Junos OS Releases 13.3, you can still
configure both fast reroute and node and link protection on the same LSP; however,
whenyouattempt to commit a configurationwhereboth featuresare enabled, a syslog
warning message displays that states: "The ability to configure both fast-reroute and
link/node-link protection on the same LSP is deprecated and will be removed in a
future release".
Multicast
• PIM snooping support using relaymode (M Series andMX Series)—Starting withJunos OS Release 13.3, PIM snooping on PE routers is supported using relay mode
insteadofproxymode.This enablesCE routerswithPIMsnooping to sendHellopackets
without setting the tracking bit (T-bit) to the PE routers. In relay mode, you need not
configurevalues for the join-prune-timeoutstatementandsave theFiniteStateMachine.
To check the status of relay mode on the CLI, use the show pim snooping neighbors
command or the show pim snooping interfaces command.
• Traffic arriving via IRBwhen configured in enhanced ip-mode—Beginningwith JunosOS Release 13.3, when configured in enhanced-ip mode, traffic arriving via IRB
(multic-ast source connected over Layer 3) is not forwarded to remote PEs in VPLS
when igmp-snooping is configured along with use-p2mp-lsp knob.
NetworkManagement andMonitoring
• Support of new system log by SNMP for notifying target addition (M Series, MXSeries, and T Series)—Beginning with Junos OS Release 13.3, when a new trap target
configuration is added to the agent, SNMP raises a new system log
SNMPD_TRAP_TARGET_ADD_NOTICE. The user can configure an event policy for this
system log event to raise a notification of the new trap target addition. This trap is sent
to all the configured trap targets including the new target.
line cards on MX Series 3D Universal Edge Routers. To configure the gre-key firewall
filter match condition, include the gre-key statement at the [edit firewall family inet
filter filter term term from] hierarchy level.
Routing Protocols
• Hidden clear commands—Starting in Junos OS Release 13.3, the purge option of theclear ospf database and clear ospf3 database commands is hidden and unsupported.
• BGP attribute flag bits—In Junos OS Release 13.2 and earlier, unused attribute flagbits were propagated unchanged. Starting in JunosOSRelease 13.3, BGP attribute flag
bits are reset to zerobydefault andnotpropagated. This behavior is being standardized,
as specified in Internet draft draft-hares-idr-update-attrib-low-bits-fix-01, Update
Attribute Flag Low Bits Clarification.
• Change inconfiguringkeepnoneandkeepallstatements—Starting in JunosOSRelease13.3, configuring keep none or keep all no longer causes all BGP sessions to restart. For
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
peers that do not support route refresh, when you configure keep none or keep all, the
associated BGP sessions are restarted (flapped). For peers that do support route
refresh, the local speaker sends a route refresh and performs an import evaluation. For
these peers, the sessions do not restart when you configure keep none or keep all. To
determine if a peer supports refresh, check for Peer supports Refresh capability in the
output of the showbgpneighbor command. In previous releases, configuring keepnone
or keep all caused all BGP sessions to restart.
• Starting in Junos OS 13.3, Junos OSmodifies the default BGP extended community
value used for MVPN IPv4 VRF route import (RT-import) to the IANA-standardized
value. Themvpn-iana-rt-import statement is the default. Themvpn-iana-rt-import
statement has been depricated and should be removed from configurations.
Services Applications
• Restriction forRPMprobetestdata-size—In JunosOSRelease 13.2andearlier releases,the data-size statement at the [edit services rpmprobeowner test test-name] hierarchy
level did not enforce any additional restrictions when the hardware-timestampwas
included. Starting in Junos OS Release 13.3, the data-size value must be at least 100
bytes smaller than the default MTU of the interface of the RPM client interface when
the hardware-timestamp statement is used.
[edit services rpm probe owner test test-name]hardware-time-stamp;data-size size;
• New ranges for TWAMP server connections—In Junos OS Release 13.2 and earlierreleases, themaximum-connections statement at the [edit services rpmtwampserver]
hierarchy level had a range of 1 through 2048. Starting in Junos OS Release 13.3, the
maximum-connections statement has a range of 1 through 1000. In Junos OS Release
13.2 and earlier releases, themaximum-connections-per-client statement at the [edit
services rpm twamp server] hierarchy level had a range of 1 through 1024. Starting in
Junos OS Release 13.3, the maximum-connections-per-client statement has a range
of 1 through 500.
• New range for data-size statement—In Junos OS Release 13.2 and earlier releases,the data-size statement at the [edit services rpmprobeowner test test-name] hierarchy
level had a range of 0 through65507. Starting in JunosOSRelease 13.3R1, thedata-size
statement has a range of 0 through 65400.
• Restriction for NAT ruleswith translation type stateful-nat-64—In JunosOSRelease13.2 and earlier releases, the following restriction was not enforced by the CLI: if the
translation-type statement in the then statement of a NAT rule was set to
stateful-nat-64, the range specified by the destination-address-range or thedestination-prefix-list in the from statement needed to be within the range specified
by thedestination-prefix statement in the then statement. Starting in JunosOSRelease
• Change in runningRPMtraceoptions—Starting in JunosOSRelease 13.2, runningRPMtraceoptions is performed from the [edit services rpm] hierarchy. Prior to Junos OS
Release 13.2, running RPM traceoptions was performed at the [edit snmp] hierarchy.
• Restrictions for maximumblock size for NAT port block allocation—Beginning withJunos OS Release 13.3, the maximum blocksize for NAT port block allocation (PBA) is
32,000.
• Support for display of NAT type for EIF flows (MX Series routers with MS-MICs andMS-MPCs)—Starting with Junos OS Release 13.3R4, the output of the show services
sessionsextensive command, theTranslationType fielddisplays the valueasNAPT-44
for Endpoint Independent Filtering (EIF) flows. Also, the label, EIF, is displayed beside
the translation type parameter to enable easy identification of EIF flows.
• Support for passive-mode tunneling (MX Series routers with MS-MICs andMS-MPCs)—Starting with Junos OS Release 13.3R4, passive mode tunneling issupported on MS-MICs and MS-MPCs. You can include the passive-mode-tunneling
statementat the [editservicesservice-setservice-set-name ipsec-vpn-options]hierarchy
level to enable the service set to tunnel malformed packets.
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
NOTE: The header-integrity-check option that is supported onMS-MICs
andMS-MPCs to verify the packet header for anomalies in IP, TCP, UDP,and ICMPinformationandflagsuchanomaliesanderrorshasafunctionalitythat is opposite to the functionality caused by passivemode tunneling. Ifyou configure both the header-integrity-check statement and the
to commit such a configuration, an error is displayed during commit.
The passivemode tunneling functionality (by including thepassive-mode-tunneling statement at the [edit services service-set
service-set-name ipsec-vpn-options] hierarchy level) is a superset of the
capability to disable IPsec tunnel endpoint in the traceroute output (byincluding no-ipsec-tunnel-in-traceroute statement at the [edit services
ipsec-vpn] hierarchy level). Passivemode tunneling also bypasses the
active IP checks and tunnel MTU check in addition to not treating an IPsectunnel as a next-hop as configured by the no-ipsec-tunnel-in-traceroute
statement.
Software Installation and Upgrade
• Upgrading Junos OS in one step (MX Series)—Starting in Junos OS Release 13.3, youcan specifymultiple configuration files in one stepwhen youupgrade JunosOSon your
device.Whenyouenter the requestsystemsoftwareaddor the requestsystemsoftware
validate command, you can use the upgrade-with-config option. You can also use the
upgrade-with-config-format option when the configuration file is in the text format.
Subscriber Management and Services
• Subscriber loginwhen lawful intercept fails—Starting in JunosOSRelease 13.3, whenlawful intercept activation fails during a subscriber login, the subscriber login is not
denied.AnSNMPmessage is still generated that indicates the lawful interceptactivation
failed. In Junos OS releases prior to 13.2R2, the subscriber login was denied if lawful
intercept activation failed.
• Change to test aaa ppp user and test aaa dhcp user commands—Starting in Junos OSRelease 13.3, the test aaapppuser and test aaadhcp user commands no longer display
serviceactivation statusbecause serviceactivation is not required in these commands.
Inearlier releases, thecommandsdisplayedserviceactivationstatus to indicatewhether
service activation failed or succeeded. Service-related RADIUS attribute values are
still displayed.
• Configuring domainmaps to use the default routing instance (MXSeries)—Startingin Junos OS Release 13.3, on MX Series routers you can explicitly configure a domain
map to use the default (master) routing instance for the AAA or subscriber contexts.
This enhancement enables you to configure a domain map to use the default routing
instance in cases where a nondefault routing instance is currently referenced, or in
other scenarios in which you need to explicitly reference the default routing instance.
• Configuration support to prevent the LACPMC-LAG system ID from reverting to thedefault LACP system ID on ICCP failure—Beginning in Junos OS Release 13.3, you canconfigure the prefer-status-control-active statement with the status-control
standbyconfiguration at the [edit interfaces aeX aggregated-ether-optionsmc-ae]
hierarchy level to prevent the LACPMC-LAG system ID from reverting to the default
LACP system ID on ICCP failure. Use this configuration only if you can ensure that ICCP
does not go down unless the router is down. Youmust also configure the hold-time
down value (at the [edit interfaces interface-name] hierarchy level) for the interchassis
link with the status-control standby configuration to be higher than the ICCP BFD
timeout. This configuration prevents traffic loss by ensuring that when the router with
the status-control active configuration goes down, the router with the status-control
standby configuration does not go into standbymode.
• Support for rejecting IPv6CP negotiation in the absence of an authorized address(MX Series)—Starting in Junos OS Release 13.3, you can control the behavior of therouter in a situationwhere IPv6CP negotiation is initiated for subscriber sessionswhen
no authorized addresses are available. By default, IPv6CP negotiation is enabled to
proceed for an IPv6-only session when AAA has not provided an appropriate IPv6
address or prefix. In the absence of the address, the negotiation cannot successfully
complete. To prevent endless client negotiation of IPv6CP, include the
reject-unauthorized-ipv6cp statement at the [edit protocols ppp-service] hierarchy
level, which enables the jpppd process to reject the negotiation attempt.
• Support for ignoring DSL ForumVSAs from directly connected devices (MXSeries)—WhenCPEdevicesaredirectly connected toaBNG, youmightwant the router
to ignore any DSL Forum VSAs that it receives in PPPoE control packets because the
VSAs can be spoofed bymalicious subscribers. Spoofing is particularly serious when
the targeted VSAs are used to authenticate the subscriber, such as Agent-Circuit-Id
[26-1] and Agent-Remote-ID [26-2].
To ignore the DSL Forum VSAs, starting in Junos OS Release 13.3, include the
direct-connect statement for PPPoE interfaces or PPPoE underlying interfaces at the
following hierarchy levels:
• [editdynamic-profilesprofile-name interfacesdemux0unit logical-unit-number family
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
You can determine whether direct-connect is configured for particular interfaces by
issuing the show interfaces or show pppoe underlying-interfaces command.
• ANCP agent behavior for invalid generic responsemessages (MX Series)—Startingin Junos OS Release 13.3, when the ANCP agent receives an incorrect or unexpected
generic responsemessage from an ANCP neighbor, it immediately drops the packet,
generates a system log notice message, and takes no further action.
• Changes toANCPshowcommandoutput (MXSeries)—Starting in JunosOSRelease13.3, the show ancp neighbor command displays information for all configured ANCP
neighbors regardless of operational state. In earlier releases, it displayed information
only for neighbors in the Established state. The Time field, which displays the elapsed
time since the neighbor entered its current state, has replaced the Up TIme field. An
asterisk (*) prefixed to the neighbor entry indicates that the adjacency information
might be stale.
In Junos OS Release 13.3 and later, the show ancp subscriber command displays
information for all subscribers regardless of operational state. In earlier releases, it
displayed information only for active subscribers in the Established state. An asterisk
(*) prefixed to the subscriber entry indicates that the information might be stale. Two
asterisks (**) indicate that the neighbor associated with the subscriber has lost its
adjacency.
• Enhancedaccountingstatistics (MSeries,MXSeries,andTSeries)—Starting in JunosOSRelease 13.3, the shownetwork-accessaaastatisticsaccounting command includes
the optional detail keyword, which provides additional information about the RADIUS
accounting statistics. You can use the enhanced details for troubleshooting
• Support for processing Cisco VSAs in RADIUSmessages for serviceprovisioning—Starting with Junos OS Release 13.3R3, Cisco VSAs are supported forprovisioning andmanagement of services in RADIUSmessages, in addition to the
supported Juniper VSAs for administration of subscriber sessions. In a deployment in
which a customer premises equipment (CPE) is connected over an access network to
a broadband remote access gateway, the Steel-Belted Radius Carrier (SBRC)
application might be used as the authentication and accounting server using RADIUS
as theprotocol and theCiscoBroadHopapplicationmightbeusedas thePolicyControl
and Charging Rules Function (PCRF) server for provisioning services using RADIUS
change of authorization (CoA)messages. Both the SBRC and the Cisco BroadHop
serversare considered tobeconnectedwith thebroadbandgateway in sucha topology.
By default, service accounting is disabled. If you configure service accounting using
both RADIUS attributes and the CLI interface, the RADIUS setting takes precedence
over the CLI setting. To enable service accounting using the CLI, include the accounting
statement at the [edit access profile profile-name service] hierarchy level. To enable
interim service accounting updates and configure the amount of time that the router
waits before sending a new service accounting update, include the update-interval
minutes statement at the [edit accessprofileprofile-name serviceaccounting]hierarchy
Youcanconfigure the router tocollect timestatistics, or bothvolumeand timestatistics,
for the service accounting sessions beingmanaged byAAA. To configure the collection
of statistical details that are time-based only, include the statistics time statement at
the [edit access profile profile-name service accounting] hierarchy level. To configure
the collection of statistical details that are both volume-time-based only, include the
statistics volume-time statement at the [edit access profile profile-name service
accounting] hierarchy level.
• Specifying the UDP port for RADIUS dynamic-request servers—Beginning in JunosOS Release 13.3, you can define the UDP port number to configure the port on which
the router that functions as theRADIUSdynamic-request servermust receive requests
from RADIUS servers. By default, the router listens on UDP port 3799 for dynamic
requests from remote RADIUS servers. You can configure the UDP port number to be
used for dynamic requests for a specific access profile or for all of the access profiles
on the router. To define the UDP port number, include the dynamic-request-port
port-number statement at the [edit access profile profile-name radius-server
server-address] or the [edit access radius-server server-address] hierarchy level.
• DCHP Relay subscriber and proxy-mode support (MX Series)—Starting with JunosOS Release 13.3, when DHCP Relay Agent for subscriber management is configured in
proxy-mode, DHCP Request packets for which no client/subscriber state exists on the
Relay Agent (stray requests) behave according to RFC 2131 Section 4.3.2: “If the DHCP
server hasno recordof this client, then itMUST remain silent, andMAYoutputawarning
to the network administrator. This behavior is necessary for peaceful coexistence of
non-communicatingDHCP servers on the samewire.” Suchbehavior also occurswhen
packets from the same client or subscriber. In some network configurations, Relay
Agent can send a NAK to the client or subscriber when Relay Agent is not configured
to act on bind-on-request. The NAK prevents Relay Agent from forwarding the DHCP
Request to the server or, in the case of a client move, when the packet is not directed
to the proxy-mode Relay Agent that receives it. DHCP Relay Agent for subscriber
management no longer generates a NAK in place of the server in response to stray
requests but relies on the server to respond appropriately to the client or subscriber.
For those cases when packets are configured not to be forwarded to the server
(no-bind-on-request is configured), orwhen thepacket isdeterminednot tobedirected
to the receiving Relay Agent, those packets are silently discarded in accordance with
RFC 2131 Section 4.3.2.
• Addition of pw-width option to the nas-port-extended-format statement—Starting inJunosOSRelease 13.3R4, you can configure the number of bits for the pseudowire field
in the extended-format NAS-Port attribute for Ethernet subscribers. Specify the value
with thepw-widthoption in thenas-port-extended-format statementat the [editaccess
profile profile-name radius options] hierarchy level. The configured fields appear in the
following order in the binary representation of the extended format:
aggregated-ethernet slot adapter port pseudo-wire stacked-vlan vlan
The width value also appears in the Cisco NAS-Port-Info AVP (100).
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
User Interface and Configuration
• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in the CLI (M Series, MX Series, and T Series)—Junos OS reserves the prefixjunos- for the identifiersofconfigurationsdefinedwithin the junos-defaultsconfiguration
group. User-defined identifiers cannot start with the string junos-. If you configured
user-defined identifiers using the reserved prefix through a NETCONF or Junos XML
protocol session, the commit correctly fails. Prior to Junos OS Release 13.3, if you
configureduser-defined identifiers through theCLI using the reservedprefix, thecommit
incorrectly succeeded. Junos OS Release 13.3 and later releases exhibit the correct
behavior. Configurations that currently contain the reserved prefix for user-defined
identifiers other than junos-defaults configuration group identifiers will now correctly
result in a commit error in the CLI.
• Change in show version command output (M Series, MX Series, and TSeries)—Beginning in JunosOSRelease 13.3, theshowversioncommandoutput includesthe new Junos field that displays the Junos OS version running on the device. This new
field is in addition to the list of installed sub-packages running on the device that also
display the Junos OS version number of those sub-packages. This field provides a
consistent means of identifying the Junos OS version, rather than extracting that
information from the list of installed sub-packages. In the future, the list of
sub-packagesmight not be usable for identifying the Junos OS version running on the
device. This change inoutputmight impact existing scripts thatparse information from
the show version command.
In Junos OS Release 13.2 and earlier, the show version command does not have the
single Junos field in theoutput thatdisplays the JunosOSversion runningon thedevice.
The only way to determine the Junos OS version running on the device is to review the
list of installed sub-packages.
Junos OS Release 13.3 and Later ReleasesWith the JunosField
Junos OS Release 13.2 and Earlier ReleasesWithout theJunos Field
user@host> show versionHostname: lab Model: mx960 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...
user@host> show versionHostname: lab Model: mx960 JUNOS Base OS boot [12.2R2.4]JUNOS Base OS Software Suite [12.2R2.4]JUNOS Kernel Software Suite [12.2R2.4]JUNOS Crypto Software Suite [12.2R2.4]...
[See show version.]
• In all supported Junos OS releases, regular expressions can no longer be configured if
they require more than 64MB of memory or more than 256 recursions for parsing.
This change in the behavior of Junos OS is in line with the FreeBSD limit. The change
wasmade in response to a known consumption vulnerability that allows an attacker
to cause a denial of service (resource exhaustion) attack by using regular expressions
containing adjacent repetition operators or adjacent bounded repetitions. Junos OS
uses regular expressions in several placeswithin theCLI. Exploitationof this vulnerability
can cause the Routing Engine to crash, leading to a partial denial of service. Repeated
exploitation can result in an extendedpartial outageof services providedby the routing
protocol process (rpd).
RelatedDocumentation
New and Changed Features on page 18•
• Known Behavior on page 62
• Known Issues on page 64
• Resolved Issues on page 73
• Documentation Updates on page 106
• Migration, Upgrade, and Downgrade Instructions on page 125
• Product Compatibility on page 134
Known Behavior
This sectioncontains theknownbehavior, systemmaximums, and limitations inhardware
and software in Junos OS Release 13.3R4 for the M Series, MX Series, and T Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
• Class of Service (CoS) on page 62
• High Availability (HA) and Resiliency on page 63
• Subscriber Management and Services on page 63
Class of Service (CoS)
• If you definemore than one forwarding class for a given queue number, do not use the
nameofadefault forwardingclass for oneof thenewclasses, becausedoing socauses
the forwarding classwith thedefault name tobedeleted. For example, donot configure
the following, because doing so deletes the best-effort class:
user@host# set class-of-service forwarding-classes class be queue-num0user@host# set class-of-service forwarding-classes class best-effort queue-num0user@host# commit
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
• Youmust disable RSTP on the ICL-PL interfaces for an MC-LAG in an active-active
bridging domain.
• The Step-by-Step Procedure section for Router PE2 that is illustrated in the example
is missing, although the quick configuration statements are presented.
To configure Router PE2:
1. Specify the number of aggregated Ethernet interfaces to be created.
[edit chassis]user@PE2# set aggregated-devices ethernet device-count 5
2. Specify the members to be included within the aggregated Ethernet bundles.
[edit interfaces]user@PE2# set ge-1/0/5 gigether-options 802.3ad ae1user@PE2# set ge-1/1/0 gigether-options 802.3ad ae0
3. Configure the interfaces that connect to senders or receivers, the ICL interfaces,and the ICCP interfaces.
[edit interfaces]user@PE2# set ge-1/0/3 flexible-vlan-tagginguser@PE2# set ge-1/0/3 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/3 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/3 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/4 flexible-vlan-tagginguser@PE2# set ge-1/0/4 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/4 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/4 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/5 gigether-options 802.3ad ae0user@PE2# set ge-1/1/0 gigether-options 802.3ad ae1
4. Configure parameters on the aggregated Ethernet bundles.
[edit interfaces ae0]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2#setunit0multi-chassis-protection 100.100.100.1 interfacege-1/0/4.0
[edit interfaces ae1]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2#setunit0multi-chassis-protection 100.100.100.1 interfacege-1/0/4.0
5. Configure LACP on the aggregated Ethernet bundles.
[edit interfaces ae0 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1
[edit interfaces ae1 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1
which link aggregation group the aggregated Ethernet interface belongs to. The
ae0 interfaces on Router PE1 and Router PE2 are configuredwithmc-ae-id 5. The
ae1 interfaces on Router PE1 and Router PE2 are configured withmc-ae-id 10.
The redundancy-group 10 statement is usedby ICCP toassociatemultiple chassis
that perform similar redundancy functions and to establish a communication
channel so thatapplicationsonpeeringchassis cansendmessages toeachother.
The ae0 and ae1 interfaces on Router PE1 and Router PE2 are configuredwith the
same redundancy group redundancy-group 10.
The chassis-id statement is used by LACP for calculating the port number of the
MC-LAG's physical member links. Router PE2 uses chassid-id 1 to identify both
its ae0 and ae1 interfaces. Router PE2 uses chassis-id 0 to identify both its ae0
and ae1 interfaces.
Themode statement indicates whether anMC-LAG is in active-standbymode or
active-activemode.Chassis thatare in thesamegroupmustbe in thesamemode.
7. Configure a domain that includes the set of logical ports.
[edit bridge-domains bd0]user@PE2# set domain-type bridgeuser@PE2# set vlan-id alluser@PE2# set service-id 20user@PE2# set interface ae0.0user@PE2# set interface ae1.0user@PE2# set interface ge-1/0/3.0user@PE2# set interface ge-1/1/1.0user@PE2# set interface ge-1/1/4.0
The ports within a bridge domain share the same flooding or broadcast
characteristics in order to perform Layer 2 bridging.
}interfaces ge-2/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;unit 1 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.
}}
}interfaces ge-3/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;family bridge {unit 1 {encapsulation vlan-vpls;interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.
}routing-instances {customer-c1-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.1;interface ge-2/0/0.1;interface ge-3/0/0.1;bridge-domains {c1-vlan-v1-to-v1000 {vlan-id all; # Note the use of the VLAN id all statement
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
customer-c2-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.11;interface ge-6/0/0.11;bridge-domains {c1-vlan-v1500 {vlan-id all; # Note the use of the VLAN id all statement
}}
} # End of customer-c1-v1500} # End of routing-instances
Note the use of the vlan-id all statement in the virtual-switch instance called
customer-c1-v1-to-v1000.
Firewall Filters Feature Guide for Routing Devices
• The following additional information regarding the decapsulation of GRE packets as
a terminatingaction for firewall filters applies to the "Firewall FilterTerminatingActions"
topic:
NOTE: Thedecapsulateaction that youconfigureat the [edit firewall family
inet filter filter-name term term-name]hierarchy leveldoesnotprocess traffic
with IPv4and IPv6options.Asa result, trafficwithsuchoptions isdiscardedby the decapsulation of GRE packets functionality.
Interchassis Redundancy Using Virtual Chassis Feature Guide for MX SeriesRouters
• In the Junos OS 13.2 Release Notes for M Series Multiservice Edge Routers, MX Series 3D
Universal Edge Routers, and T Series Core Routers, the Support for MX Series Virtual
that you can configure a two-member MX Series Virtual Chassis on both MPC3E
modules and MPC4Emodules. The correct description for this feature is as follows:
• Support forMXSeriesVirtualChassisonMXSeries routerswithMPC3EandMPC4Einterfaces—Extendssupport for configuringa two-memberMXSeriesVirtualChassisto MX240, MX480, andMX960 routers with any of the followingmodules installed:
[See Junos OSHigh Availability Library for Routing Devices and Junos OS for MX Series
3D Universal Edge Routers.]
• The followingadditional informationapplies to theVirtualChassisComponentsOverview
topic in the Interchassis Redundancy Using Virtual Chassis Feature Guide for MX Series
Routers for Junos OS Release 11.2 and later releases.
When you configure chassis properties for MPCs installed in a member router in an
MX Series Virtual Chassis, keep the following points in mind:
• Statements included at the [edit chassis membermember-id fpc slot slot-number]
hierarchy level apply to the MPC (FPC) in the specified slot number only on the
specified member router in the Virtual Chassis.
For example, if you issue the set chassis member 0 fpc slot 1 power off statement,
only the MPC installed in slot 1 of member ID 0 in the Virtual Chassis is powered off.
• Statements included at the [edit chassis fpc slot slot-number] hierarchy level apply
to theMPCs(FPCs) in thespecifiedslotnumberoneachmember router in theVirtual
Chassis.
For example, if you issue the set chassis fpc slot 1 power off statement in a
two-member MX Series Virtual Chassis, both the MPC installed in slot 1 of member
ID 0 and the MPC installed in slot 1 of member ID 1 are powered off.
BEST PRACTICE: To ensure that the statement you use to configure MPCchassis properties in a Virtual Chassis applies to the intendedmemberrouter andMPC, we recommend that you always include themember
member-ID option before the fpc keyword, wheremember-id is 0 or 1 for a
two-member MX Series Virtual Chassis.
IP Demux Interfaces over Static or Dynamic VLANDemux Interfaces
• The “IP Demux Interfaces over Static or Dynamic VLAN Demux Interfaces” topic
incorrectly states thatbothDPCsandMPCssupportVLANdemuxsubscriber interfaces.
In fact, only MPCs support these interfaces.
Junos Address-Aware Carrier-Grade NAT and IPv6 Feature Guide
• The followingnoteapplies to the topic “ConfiguringAddressPools forNetworkAddress
Port Translation (NAPT) Overview”:
NOTE: When 99 percent of the total available ports in a pool for napt-44are used, no new flows are allowed on that NAT pool.
• Several errors were found in the configuration statements included in the “Example:
Configuring Inline Network Address Translation” topic. The topic has been corrected
on theweband in the “JunosAddressAwareCarrierGradeNATand IPv6FeatureGuide”
sequence number or is unique, it is disregarded and not considered.
The following additional fields are missing from the Lines of Sample DTCP Parameter
File table:
DescriptionCommand
This indicates the DTCP version to be used. DTCP/0.6 should be used for all versions of Junos OS upto and including Junos OS 8.5. DTCP/0.7 should be used for Junos OS 9.0 and later. However, JunosOS 9.5R2 and later also accept previous versions of DTCP.
If any unsupported parameters are received for a particular DTCP version, the request is rejected.
NOTE: The notification responses from Junos OS contains the same DTCP version that the controlsource has communicated to Junos OS. For notifications being sent even before the control sourcehas contacted Junos OS, the DTCP version 0.7 will be used.
DELETE DTCP/0.6
This line denotes the ID that DTCP assigns for the mirrored session when you create a DTCP ADDmessage. Use this ID in your DELETEmessages to disable the intercept for a specific subscriber. Toview the ID, use the DTCP LISTmessage. The CRITERIA-ID and the Cdest-ID are mutually exclusive inDELETEmessages.
CRITERIA-ID:criteria-id
[See Flow-Tap Filter Operation.]
• The following additional information applies to the sample configuration described in
the “Example: Flow-Tap Configuration” topic of the “FlowMonitoring” chapter.
NOTE: Thedescribedexampleappliesonly toMSeriesandTSeries routers,except M160 and TXMatrix routers. For MX Series routers, because theflow-tap application resides in the Packet Forwarding Engine rather thana service PIC or Dense Port Concentrator (DPC), the Packet ForwardingEnginemust send the packet to a tunnel logical (vt-) interface toencapsulate the interceptedpacket. In suchascenario, youneed toallocatea tunnel interface and assign it to the dynamic flow capture process forFlowTapLite to use.
• The following information is missing from the passive-mode-tunneling configuration
statement and the “Example: Configuring Junos VPN Site Secure on MSMIC and
MS-MPC” topic:
Passive module tunneling is not supported on MS-MICs and MS-MPCs.
• Theopen-timeout configuration statement topic and the “ConfiguringDefault Timeout
Settings for Services Interfaces” topic incorrectly state that the default value of the
timeout period for TCP session establishment is 30 seconds. The correct default value
is 5 seconds.
• The Supported Platforms section of theset chassis displaymessage command topic
erroneously states that this command is supportedonMXSeries routers.This command
is not available on MX Series routers.
• The following procedure applies to the “Provisioning Flow-Tap to a Linux Mediation
Device” topic
The following example shows the syntax to invoke the Perl script from a Linux device
for deleting a previously configured Flow-Tap session:
1. Invoke the Perl script:
[root@blr-e flowtap]# ./dfcclient.pl
2. Use the following line to push the parameter file del_lea1_tcp.flowtap to the router.
In this example, 10.209.75.199 is the IP address of the router, and verint verint123 is
the username and password that has permission to implement flow-tap-operation.
Any firewall that is between themediation device and the routing device should
NOTE: With JunosOSRelease 9.0 and later, the compact flash diskmemoryrequirement for Junos OS is 1 GB. For M7i andM10i routers with only 256MBmemory, see the Customer Support Center JTAC Technical BulletinPSN-2007-10-001 athttps://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001
&actionBtn=Search
NOTE: Before upgrading, back up the file system and the currently activeJunos OS configuration so that you can recover to a known, stableenvironment in case the upgrade is unsuccessful. Issue the followingcommand:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstallsJunos OS. Configuration information from the previous software installationis retained, but the contents of log files might be erased. Stored files on therouting platform, such as configuration templates and shell scripts (the onlyexceptions are the juniper.conf and ssh files) might be removed. To preserve
the stored files, copy them to another system before upgrading ordowngrading the routing platform. For more information, see the Junos OS
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.
• All master Routing Engines in all routers run the same version of software. This is
necessary for the routing matrix to operate.
• All master and backup Routing Engines run the same version of software before
beginning the upgrade procedure. Different versions of the Junos OS can have
incompatible message formats especially if you turn on GRES. Because the steps in
the process include changing mastership, running the same version of software is
recommended.
• For a routing matrix with a TXMatrix router, the same Routing Engine model is used
within a TXMatrix router (SCC) and within a T640 router (LCC) of a routing matrix.
For example, a routing matrix with an SCC using two RE-A-2000s and an LCC using
two RE-1600s is supported. However, an SCC or an LCC with two different Routing
Engine models is not supported. We suggest that all Routing Engines be the same
model throughout all routers in the routing matrix. To determine the Routing Engine
type, use the CLI show chassis hardware | match routing command.
• For a routing matrix with a TXMatrix Plus router, the SFC contains twomodel
RE-DUO-C2600-16G Routing Engines, and each LCC contains twomodel
RE-DUO-C1800-8G or RE-DUO-C1800-16G Routing Engines.
BEST PRACTICE: Make sure that all master Routing Engines are re0 and allbackup Routing Engines are re1 (or vice versa). For the purposes of thisdocument, themaster Routing Engine is re0 and the backup Routing Engineis re1.
To upgrade the software for a routing matrix, perform the following steps:
Release Notes: Junos OS Release 13.3R4 for the EX Series, M Series, MX Series, PTX Series, and T Series
[edit]
user@host# set protocols pim nonstop-routing disableuser@host# activate protocols pimuser@host# commit
Downgrading fromRelease 13.3
To downgrade from Release 13.3 to another supported release, follow the procedure for
upgrading, but replace the 13.3 jinstall package with one that corresponds to the
appropriate release.
NOTE: Youcannot downgrademore than three releases. For example, if yourrouting platform is running Junos OS Release 11.4, you can downgrade thesoftware to Release 10.4 directly, but not to Release 10.3 or earlier; as aworkaround, you can first downgrade to Release 10.4 and then downgradeto Release 10.3.
For more information, see the Installation and Upgrade Guide.
Changes Planned for Future Releases
The following are changes planned for future releases.
Routing Protocols
• Change in Junos OS support for the BGPMonitoring Protocol (BMP)—In Junos OSRelease 13.3and later, thecurrently supportedversionofBMP,BMPversion 1, asdefined
in Internet draft draft-ietf-grow-bmp-01, is planned to be replaced with BMP version
3, as defined in Internet draft draft-ietf-grow-bmp-07.txt. Junos OS can support only
one of these versions of BMP in a release. Therefore, Junos OS Release 13.2 and earlier
releases will continue to support BMP version 1, as defined in Internet draft
draft-ietf-grow-bmp-01. Junos OS Release 13.3 and later support only the updated
BMP version 3 defined in Internet draft draft-ietf-grow-bmp-07.txt. This also means
thatbeginning in JunosOSRelease 13.3,BMPversion3configurationsarenotbackwards
compatible with BMP version 1 configurations from earlier Junos OS releases.
• Removalofsupport forproviderbackbonebridging(MXSeries routers) fromRelease14.1—Starting with Junos OS Release 14.1, the provider backbone bridging (PBB)capability is disabled and not supported on MX Series routers. The pbb-options
statementand its substatementsat the [edit routing-instances routing-instance-name]
hierarchy level and the pbb-service-options statement and its substatements at the
• Support for strict-priority scheduling (PTX Series)—Beginning with Junos OS Release
13.3, interfaces on PTX Series routers support strict-priority scheduling. Configured
queues are processed in strict-priority order. Within the guaranteed region, multiple
CoS queues that compete in the same hardware-based priority level are selected
based on the packet round-robin algorithm, while within the excess region, selection
is based on theWRR algorithm. The queues receive equal share when they send the
same packet size. Otherwise, the queues receive shares proportional to the respective
packet sizes sent. To enable configuration of strict-priority scheduling for a physical
interface on a PTX Series router, include the strict-priority-scheduler statement in the
traffic control profile associated with the interface.
[See Understanding Scheduling on PTX Series Routers.]
General Routing
• Nonstop active routing support for logical systems (PTX Series)—Starting in Junos
OSRelease 13.3, this featureenablesnonstopactive routing support for logical systems
using the nonstop-routing option under the [edit logical-systems logical-system-name
routing-options] hierarchy. As a result of extending nonstop active routing support for
logical systems, the logical-systems argument has been appended in some show
operational commands to allow display of status, process, and event details.
High Availability (HA) and Resiliency
• Nonstop active routing support for BGP addpath (PTX Series)—Beginning in JunosOS Release 13.3, nonstop active routing support for BGP addpath is available on the
PTX Series. Nonstop active routing support is enabled for the BGP addpath feature.
After the nonstop active routing switchover, addpath-enabled BGP sessions do not
bounce. The secondary Routing Engine maintains the addpath advertisement state
before the nonstop active routing switchover.
Interfaces and Chassis
• FPC self-healing (PTX Series)—Starting in Junos OS Release 13.3, PTX Series routersallow you to configure Packet Forwarding Engine-related error levels (fatal, major, or
minor) and the actions to perform (alarm, disable-pfe, or log) when a specified
threshold is reached.Previously, Packet ForwardingEngine-relatederrorswoulddisable
the FPC. Using this commandPacket Forwarding Engine errors can be isolated thereby
reducing the need for a field replacement. This command is available at the [edit
chassis fpc slot-number] and [edit chassis] hierarchy levels.
• 2-port 100-Gigabit DWDMOTNPIC (PTX3000)—Beginning with Junos OS Release13.3, the 2-port 100-Gigabit dense wavelength division multiplexing (DWDM) optical
transport network (OTN) PIC is supported by Type 5 FPCs on PTX3000 routers. The
100-Gigabit DWDMOTN PIC supports the following features:
• Transparent transport of two 100-Gigabit Ethernet signals with OTU4 framing
• ITU-standard OTN performancemonitoring and alarmmanagement
• Support for configuring interface alias names (PTX Series)—Beginning in Junos OSRelease 13.3, you can configure a textual description of a physical interface or the
logical unit of an interface to be the alias of an interface name. If you configure an
interface alias, this alias name is displayed in the output of the show interfaces
commands instead of the interface name. Also, in the output of all of the show and
operational mode commands that display the interface names, the alias name is
displayed instead of the interface name if you configure the alias name. It has no effect
on theoperationof the interfaceon the router or switch.Youcanuse thealias statement
at the [edit interfaces interface-name], [edit interfaces interface-name unit
logical-unit-number], and [edit logical-systems logical-system-name interfaces
interface-name unit logical-unit-number] hierarchy levels to specify an interface alias.
[See Interface Alias NameOverview]
• Support for active flowmonitoring version 9 (PTX5000 routers withCSE2000)—Starting with Junos OS Release 13.3, Carrier-Grade Service Engine(CSE2000) supports active flowmonitoring version 9 on PTX5000 routers.
TheCSE2000 is tethered toaPTX5000router toenableactive flowmonitoringversion
9.Active flowmonitoring version9 supports IPV4,MPLS, and IPV6 templates to collect
a set of sampled flows and send the records to a specified host.
• SFPP-10G-CT50-ZR (PTX Series)—Beginning in Junos OS Release 13.3R3, theSPFF-10G-CT50-ZR tunable transceiver provides a duplex LC connector and supports
the 10GBASE-Z optical interface specification andmonitoring. The transceiver is not
specified as part of the 10-Gigabit Ethernet standard and is instead built according to
Juniper Networks specifications. OnlyWAN-PHY and LAN-PHYmodes are supported.
To configure the wavelength on the transceiver, use thewavelength statement at the
• SFPP-10G-ZR-OTN-XT (PTX Series)—Starting with Junos OS Release 13.3R3, theSFPP-10G-ZR-OTN-XTdual-rate extended temperature transceiver provides aduplex
LC connector and supports the 10GBASE-Z optical interface specification and
monitoring. The transceiver is not specified as part of the 10-Gigabit Ethernet standard
and is instead built according to ITU-T and Juniper Networks specifications. The
following interface modules support the SFPP-10G-ZR-OTN-XT transceiver:
PTX:
• 10-Gigabit Ethernet PIC with SFP+ (model number:
P1-PTX-24-10GE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and
later
• 10-Gigabit Ethernet LAN/WANOTN PIC with SFP+ (model number:
P1-PTX-24-10G-W-SFPP)—Supported in JunosOSRelease 12.3R5, 13.2R3, 13.3, and
later
Formore informationabout interfacemodules, see the “CablesandConnectors” section
in the Interface Module Reference for your router.
• OTN support for PTX Series—Starting in Junos OS Release 13.3, you can configureOTNmode on 10-Gigabit Ethernet interfaces on PTX Series Packet Transport Routers.
Only the 24-port 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (model number:
P1-PTX-24-10G-W-SFPP) supports OTNmode. The following OTN framingmodes
are supported:
• 10-Gigabit Ethernet LAN-PHY over OTU2e/OTU1e
• 10-Gigabit EthernetWAN-PHY over OTU2
The following forward error correction (FEC) types are supported:
You canmonitor various transport features like 24-hour bins and transport states by
using the transport-monitoring statement at the [edit interfaces] hierarchy level.
• Support for active flowmonitoring version 9 (PTX3000 routers withCSE2000)—Starting with Junos OS Release 13.3R4, Carrier-Grade Service Engine(CSE2000) supports active flowmonitoring version 9 on PTX3000 routers.
TheCSE2000 is tethered toaPTX3000router toenableactive flowmonitoringversion
9. Active flowmonitoring version 9 supports IPv4,MPLS, and IPv6 templates to collect
a set of sampled flows and send the records to a specified host.
NetworkManagement andMonitoring
• Support for BFD over child links of AE or LAG bundle (cross-functional PacketForwarding Engine/kernel/rpd) (PTX Series)—Beginning in Junos OS Release 13.3,BFDover child links of anAEor LAGbundle is supportedon thePTXSeries. This feature
provides a Layer 3 BFD liveness detection mechanism for child links of the Ethernet
LAG interface. You can enable BFD to run on individual member links of the LAG to
monitor theLayer 3or Layer 2 forwardingcapabilitiesof individualmember links. These
micro BFD sessions are independent of each other despite having a single client that
manages the LAG interface. To enable failure detection for aggregated Ethernet
interfaces, include the bfd-liveness-detection statement at the [edit interfaces aex
[See Understanding Independent Micro BFD Sessions for LAG.]
Routing Protocols
• Bidirectional PIM support (PTX5000)—Beginning with Junos OS Release 13.3,bidirectional PIM is supported on the PTX5000. The following caveats are applicable
for the bidrectional PIM configuration on the PTX 5000:
• The PTX5000 can be configured both as a bidirectional PIM rendezvous point and
the source node.
• For the PTX5000, you can configure the auto-rp statement at the [edit protocols
pimrp]or the [edit routing-instances routing-instance-nameprotocolspimrp]hierarchy
level with themapping option, but not the announce option.
you to upgrade between two different Junos OS releases with no disruption on the
control plane and with minimal disruption of traffic.
[See Unified ISSU System Requirements.]
RelatedDocumentation
Changes in Behavior and Syntax on page 141•
• Known Issues on page 143
• Resolved Issues on page 145
• Documentation Updates on page 151
• Migration, Upgrade, and Downgrade Instructions on page 151
• Product Compatibility on page 154
Changes in Behavior and Syntax
This section lists the changes in behavior of JunosOS features and changes in the syntax
of JunosOSstatementsandcommands fromJunosOSRelease 13.3R4 for thePTXSeries.
• Interfaces and Chassis on page 141
• Routing Protocols on page 142
• User Interface and Configuration on page 142
Interfaces and Chassis
• In Junos OS Releases 13.2R4, 13.3R2, the interpolated fill level of 0 percent has a drop
probability of 0 percent for weighted random early detection (WRED). In earlier Junos
OS releases, interpolatedWRED can have a nonzero drop probability for a fill level of
0 percent, which can cause packets to be dropped even when the queue is not
congested or the port is not oversubscribed.
• Exporting active flowmonitoring version 9 packets fromCSE2000 to PTX Seriesrouters—Starting with Junos OS Release 13.3R4, active flowmonitoring version 9
records created by CSE2000 are sent back to PTX Series Routers on the 10-Gigabit
Ethernet interface. The PTX Series routers then forward the version 9 flow records to
the version 9 flow server.
In releases before Junos OS 13.3R4, the version 9 records are sent to the version 9 flow
server by means of a separate external collector port. PR985729
• Junos OSmodifies the default BGP extended community value used for MVPN IPv4
VRF route import (RT-import) to the IANA-standardized value. The behavior of the
mvpn-iana-rt-import statement is nowthedefault. Themvpn-iana-rt-import statement
has been deprecated and should be removed from configurations.
User Interface and Configuration
• User-defined identifiersusingthereservedprefix junos-nowcorrectlycauseacommiterror in the CLI (PTXSeries)—Junos OS reserves the prefix junos- for the identifiers ofconfigurations defined within the junos-defaults configuration group. User-defined
identifiers cannot start with the string junos-. If you configured user-defined identifiers
using the reserved prefix through a NETCONF or Junos XML protocol session, the
commit would correctly fail. Prior to Junos OS Release 13.3, if you configured
user-defined identifiers through the CLI using the reserved prefix, the commit would
incorrectly succeed. Junos OS Release 13.3 and later releases exhibit the correct
behavior. Configurations that currently contain the reserved prefix for user-defined
identifiers other than junos-defaults configuration group identifiers will now correctly
result in a commit error in the CLI.
• Change in show version command output (PTX Series)—Beginning in Junos OSRelease 13.3, the show version command output includes the new Junos field that
displays the Junos OS version running on the device. This new field is in addition to the
list of installed sub-packages running on the device that also display the Junos OS
version number of those sub-packages. This field provides a consistent means of
identifying the Junos OS version, rather than extracting that information from the list
of installed sub-packages. In the future, the list of sub-packages might not be usable
for identifying the JunosOS version running on the device. This change in outputmight
impact existing scripts that parse information from the show version command.
In Junos OS Release 13.2 and earlier, the show version command does not have the
single Junos field in theoutput thatdisplays the JunosOSversion runningon thedevice.
The only way to determine the Junos OS version running on the device is to review the
list of installed sub-packages.
Junos OS Release 13.3 and Later ReleasesWith the JunosField
Junos OS Release 13.2 and Earlier ReleasesWithout theJunos Field
user@host> show versionHostname: lab Model: ptx5000 Junos: 13.3R1.4JUNOS Base OS boot [13.3R1.4] JUNOS Base OS Software Suite [13.3R1.4] JUNOS 64-bit Kernel Software Suite [13.3R1.4]JUNOS Crypto Software Suite [13.3R1.4]...
user@host> show versionHostname: lab Model: ptx5000 JUNOS Base OS boot [12.3R2.5]JUNOS Base OS Software Suite [12.3R2.5]JUNOS 64–bit Kernel Software Suite [12.3R2.5]JUNOS Crypto Software Suite [12.3R2.5]...
and save the configuration change to both Routing Engines.
2. Install the new Junos OS release on the backup Routing Engine while keeping the
currently running software version on themaster Routing Engine.
3. After making sure that the new software version is running correctly on the backup
RoutingEngine, switchover to thebackupRoutingEngine toactivate thenewsoftware.
4. Install the new software on the original master Routing Engine that is now active as
the backup Routing Engine.
For the detailed procedure, see the Installation and Upgrade Guide.
Basic Procedure for Upgrading to Release 13.3
When upgrading or downgrading Junos OS, use the jinstall package. For information
about the contents of the jinstall package and details of the installation process, see the
Installation and Upgrade Guide. Use other packages, such as the jbundle package, only
when so instructed by a Juniper Networks support representative.
NOTE: Backupthe file systemandthecurrentlyactive JunosOSconfigurationbefore upgrading Junos OS. This allows you to recover to a known, stableenvironment if the upgrade is unsuccessful. Issue the following command:
user@host> request system snapshot
NOTE: The installation process rebuilds the file system and completelyreinstalls Junos OS. Configuration information from the previous softwareinstallation is retained, but the contents of log files might be erased. Storedfiles on the router, suchas configuration templatesandshell scripts (theonlyexceptions are the juniper.conf and ssh files),might be removed. To preservethe stored files, copy them to another system before upgrading ordowngrading the routing platform. For more information, see the Junos OS
NOTE: We recommend that you upgrade all software packages out of bandusing the console because in-band connections are lost during the upgradeprocess.
Thedownloadand installationprocess for JunosOSRelease 13.3 isdifferent fromprevious
Junos OS releases.
1. Using aWeb browser, navigate to the All Junos Platforms software download URLon the Juniper Networks webpage:
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 Softwarepage.
4. Select the Software tab.
5. In the Install Package section of the Software tab, select the software package forthe release.
6. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
7. Review and accept the End User License Agreement.
8. Download the software to a local host.
9. Copy the software to the routing platform or to your internal software distribution
site.
10. Install the new jinstall package on the router.
NOTE: After you install a Junos OS Release 13.3 jinstall package, youcannot issue the request system software rollback command to return tothe previously installed software. Instead youmust issue the requestsystem software add validate command and specify the jinstall packagethat corresponds to the previously installed software.
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.
Customers in the United States and Canada, use the following command:
user@host> request system software add validate rebootsource/jinstall-13.3R41-domestic-signed.tgz
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.