JUNOS OS 14.2 RELEASE NOTES ®

Transcription

JUNOS® OS 14.2
RELEASE NOTES
INSIDE THIS RELEASE
Supported on EX Series, M Series, MX Series, PTX Series, and T Series
NEW SOFTWARE FEATURES
·
·
·
·
·
·
·
·
Ethernet alarm indication signal (MX Series)
Inline active flow monitoring (T4000 routers with T4000-FPC5-3D)
IPv6 support for aggregated multiservices (AMS) interfaces (MX Series with MS-MPCs)
Mixed rates on aggregated Ethernet bundles (MX Series)
OpenFlow v1.3.1 (EX9204, EX9208, EX9214, and MX Series)
User-configurable traffic class map (T4000 routers with Type 5 FPC)
VXLAN and OVSDB (EX9204, EX9208, and EX9214)
Walkup for route filters (M Series, MX Series, T Series, and PTX Series)
NEW DEVICES AND MODULES
·
·
·
·
4-port 100-Gigabit Ethernet OTN PIC (PTX5000)
10-Gigabit Ethernet/40-Gigabit Ethernet LAN/WAN PIC with QSFP+ (PTX5000)
High Capacity AC PDU (Wye and Delta) and High Capacity AC PSM (PTX5000)
Multiservices MIC support (MX104)
RECENTLY RELEASED DOCUMENTATION
·
·
·
·
·
·
·
Day One: Juniper Ambassadors' Cookbook 2014
Learn About Firewall Design
Learn About Firewall Evolution
NCE — Configuring Inline Video Monitoring Using Media Delivery Index Metrics
NCE — Configuring Interchassis Redundancy for MX Series 3D Universal Edge Routers Using a Virtual Chassis
NCE — Configuring Mixed Mode Support for Dynamic MLPPP Subscribers
Video: Handling Ingress Oversubscription on T4000 Routers with Type 5 FPCs
http://juniper.net/documentation
Release Notes: Junos OS for the EX Series, M Series, MX Series, PTX Series, and T Series
ii
Copyright © 2014, Juniper Networks, Inc.
®
Release Notes: Junos OS Release 14.2R1
for the EX Series, M Series, MX Series,
PTX Series, and T Series
12 November 2014
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Junos OS Release Notes for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Bridging and Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Open vSwitch Database Management Protocol (OVSDB) . . . . . . . . . . . . 7
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Open vSwitch Database (OVSDB) Management Protocol . . . . . . . . . . . 13
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1
Release Notes: Junos OS Release 14.2R1 for the EX Series, M Series, MX Series, PTX Series, and T Series
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 15
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . . 15
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D
Universal Edge Routers, and T Series Core Routers . . . . . . . . . . . . . . . . . . . . . 17
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authentication, Authorization, and Accounting (AAA) (RADIUS) . . . . . . 19
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Operation, Administration, and Maintenance (OAM) . . . . . . . . . . . . . . . . 33
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Multiprotocol Label Switching (MPLS) . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
User Access and Authorization Feature Guide for Routing Devices . . . . . 52
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . . . 53
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 55
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . . 55
Upgrading Juniper Network Routers Running Draft-Rosen Multicast
VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . . 57
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled
for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Downgrading from Release 14.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Changes Planned for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Junos OS Release Notes for PTX Series Packet Transport Routers . . . . . . . . . . . . 63
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . . 71
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . . . 72
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3
Third-Party Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4
Introduction
Introduction
®
Junos OS runs on the following Juniper Networks hardware: ACX Series, EX Series, J
Series, M Series, MX Series, PTX Series, QFabric, QFX Series, SRX Series, and T Series.
These release notes accompany Junos OS Release 14.2R1 for the EX Series, M Series, MX
Series, PTX Series, and T Series. They describe new and changed features, limitations,
and known and resolved problems in the hardware and software.
Junos OS Release Notes for EX Series Switches
These release notes accompany Junos OS Release 14.2R1 for the EX Series. They describe
new and changed features, limitations, and known and resolved problems in the hardware
and software.
You can also find these release notes on the Juniper Networks Junos OS Documentation
webpage, located at https://www.juniper.net/junos/.
•
New and Changed Features on page 5
•
Changes in Behavior and Syntax on page 11
•
Known Behavior on page 12
•
Known Issues on page 13
•
Documentation Updates on page 15
•
Migration, Upgrade, and Downgrade Instructions on page 15
•
Product Compatibility on page 16
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R1 for the EX Series.
•
Authentication and Access Control
•
Bridging and Learning
•
Class of Service
•
Management
•
Network Management and Monitoring
•
Open vSwitch Database Management Protocol (OVSDB)
•
OpenFlow
•
Port Security
•
Routing Policy and Firewall Filters
•
Software Installation and Upgrade
•
User Interface and Configuration
•
VPNs
•
VXLAN
5
Authentication and Access Control
•
Access control (EX9200)—Starting with Junos OS Release 14.2, EX9200 switches
support controlling access to your network by using several different authentication
methods: 802.1X authentication, MAC RADIUS authentication, or captive portal. You
now enable the authentication-whitelist statement at the [edit switching-options]
hierarchy level instead of at the [edit ethernet-switching-options] hierarchy level. [See
Access Control on EX9200 Switches].
Bridging and Learning
•
Support for PVLANs (EX9200)—Starting with Junos OS Release 14.2, EX9200 switches
support private VLANs (PVLANs). PVLANs are useful for restricting the flow of broadcast
and unknown unicast traffic and for limiting communication between known hosts.
PVLANs help ensure the security of service providers sharing a server farm, or to provide
security to subscribers of various service providers sharing a common metropolitan
area network.
NOTE: An interface can belong to only one PVLAN domain.
[See Understanding Private VLANs on EX Series Switches.]
Class of Service
•
Layer 2 class of service (CoS) support (EX9200)—Starting with Junos OS Release
14.2R1, EX9200 switches support the following Layer 2 CoS features: DSCP IPv4 and
DSCP IPv6 rewrite on Layer 2 access and trunk ports, inet-precedence rewrite on Layer
2 access and trunk ports, IEEE 802.1p rewrite on access ports, and IEEE 802.1p classifiers
on access ports. The rewrite feature enables you to change the code point bits of
packets when they egress the switch. Classification groups packets into forwarding
classes at the ingress interface, based on the IEEE 802.1p code point in the Ethernet
frame header. (Classification can also use DSCP IPv4 or DSCP IPv6 code points. You
can configure both an IEEE 802.1p classifier and a DSCP classifier on the same port.)
You can configure the new Layer 2 CoS support features at the [edit class-of-service
rewrite-rules] and the [edit class-of-service classifier] hierarchy levels.
[For information about rewriting, see Rewriting Packet Header Information on EX9200
Switches. For information about classification, see Classifying Packets by Behavior
Aggregate on EX9200 Switches.]
6
Management
•
YANG module that defines the Junos OS configuration hierarchy (EX9200)—Starting
with Junos OS Release 14.2, Juniper Networks provides a YANG module, which defines
the Junos OS configuration hierarchy. You can download the YANG module that defines
the complete Junos OS configuration hierarchy for all devices running a particular Junos
OS release from the Juniper Networks website at http://www.juniper.net/. You can also
generate a YANG module that defines the device-specific configuration hierarchy by
using the show system schema module configuration format yang operational mode
command on the local device. The Juniper Networks YANG module, configuration, is
bound to the namespace URI http://yang.juniper.net/yang/1.1/jc and uses the prefix jc.
[See Understanding YANG on Devices Running Junos OS.]
•
Enhancements to SNMP statistics operational mode commands (EX9200)—Starting
with Junos OS Release 14.2, you can use the show snmp stats-response-statistics
command to view information about SNMP statistics responses sent from the Packet
Forwarding Engine during the MIB II process (mib2d). In addition, you can use the
subagents option in the show snmp statistics command to view the statistics of the
protocol data units (PDUs) and the number of SNMP requests and responses per
subagent. You can also use the subagents option to view the SNMP statistics received
from each subagent on each logical system.
[See show snmp stats-response-time and show snmp statistics.]
Open vSwitch Database Management Protocol (OVSDB)
•
OVSDB support (EX9200)—The Junos OS implementation of the Open vSwitch
Database (OVSDB) management protocol provides a means by which VMware NSX
controllers and EX9200 switches that support OVSDB can communicate. In an NSX
multi-hypervisor environment, NSX controllers and EX9200 switches can exchange
control and statistical information, thereby enabling virtual machine (VM) traffic from
entities in a virtual network to be forwarded to entities in a physical network the reverse.
[See Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices and “Product Compatibility” on page 16.]
7
OpenFlow
•
Support for OpenFlow v1.3.1 (EX9200)—Starting with Junos OS Release 14.2, EX9200
switches support OpenFlow v1.3.1 in addition to the OpenFlow v1.0 functionality that
is already supported on EX9200 switches. OpenFlow v1.3.1 allows the action specified
in one or more flow entries to direct packets to a base action called a group. The purpose
of the group action is to further process these packets and assign a more specific
forwarding action to them. You can view groups that were added, modified, or deleted
from the group table by the OpenFlow controller using the show openflow groups
command. You can view group statistics using the show openflow statistics groups
command.
[See Understanding How the OpenFlow Group Action Works.]
Port Security
•
IPv6 access security (EX9200)—Starting with Junos OS Release 14.2, IPv6 access
security is supported on EX9200 switches with the following features: DHCPv6
snooping, IPv6 neighbor discovery inspection, IPv6 source guard, and RA guard. DHCPv6
snooping enables a switch to process DHCPv6 messages between a client and a server
and build a database of the IPv6 addresses assigned to the DHCPv6 clients. The switch
can use this database, also known as the binding table, to stop malicious traffic. The
EX9200 also supports DHCPv6 options to provide additional information to the
messages sent by the client towards the server. This information can be used by the
server to assign addresses and configuration parameters to the client. The following
options are supported:
•
Option 37, also known as the Remote-ID option, is used to transmit information
about the remote host.
•
Option 18, also known as the Interface-ID option, is used to transmit information
about the port on which the DHCPv6 request was received from the client.
•
Option 16, also known as the Vendor-Class option, is used to transmit information
about the vendor of the hardware on which the client is hosted.
IPv6 neighbor discovery inspection analyzes neighbor discovery messages and Router
Advertisement (RA) messages, sent from IPv6 nodes on the same link, and verifies
them against the DHCPv6 binding table. IPv6 source guard inspects all IPv6 traffic
from the client and verifies the source IPv6 address and source MAC address against
the entries in the DHCPv6 binding table. If no match is found, the traffic is dropped.
You configure DHCPv6 snooping, DHCPv6 options, IPv6 neighbor discovery Inspection,
and IPv6 source guard at the [edit vlans vlan-name forwarding-options dhcp-security]
hierarchy level.
[See Understanding Port Security.]
•
8
Unknown unicast forwarding (EX9200)—Unknown unicast traffic consists of unicast
packets with unknown destination MAC addresses. By default, the switch floods these
unicast packets that are traveling in a VLAN to all interfaces that are members of the
VLAN. Forwarding this type of traffic can create unnecessary traffic that leads to poor
network performance or even a complete loss of network service. This is known as a
traffic storm.
To prevent a storm, you can disable the flooding of unknown unicast packets to all
VLAN interfaces by configuring one VLAN or all VLANs to forward all unknown unicast
traffic to a specific interface. This channels the unknown unicast traffic to a single
interface.
Configure unknown unicast forwarding at these hierarchy levels:
•
[edit vlans vlan-name forwarding-options flood input uuf-filter-name]
•
[edit forwarding-options next-hop-group next-hop-group-name group-type layer-2
interface interface-name]
•
[edit firewall family ethernet-switching filter uuf-filter-name term term-name from
traffic-type unknown-unicast]
•
[edit firewall family ethernet-switching filter uuf-filter-name term term-name then
next-hop-group next-hop-group-name]
[See Understanding Unknown Unicast Forwarding.]
9
•
Firewall filter match condition support (EX9200)—Starting with Junos OS Release
14.2R1, EX9200 switches support the following match conditions in a
family-ethernet-switching filter for IPv6 traffic: destination-address,
destination-prefix-list, source-address, source-prefix-list, icmp-type, icmp-code,
next-header, source-port, destination-port, tcp-flags, tcp-initial, tcp-established, and
traffic-class. You can configure these match conditions at the [edit firewall family
ethernet-switching filter filter-name term term-name from] hierarchy level.
[See Firewall Filters for EX9200 Switches.]
•
Support for unified-in-service software upgrade on 10-Gigabit Ethernet, 40-Gigabit
Ethernet, and 100-Gigabit Ethernet line cards (EX9200)—Starting with Junos OS
Release 14.2, unified-in-service software upgrade (unified ISSU) is now supported on
EX9200 switches on 10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet
line cards. Unified ISSU is a process to upgrade the Junos OS with minimal disruption
of transit traffic and no disruption of the control plane. This process is for upgrading
Junos OS from an earlier release to a later one. After the unified ISSU completes, the
new upgrade works identical to one performed through a cold boot.
Configure unified ISSU with the request system software in-service-upgrade command.
[See Unified ISSU System Requirements.]
•
Enhancement to reduce the time taken for performing system commit
(EX9200)—Starting with Junos OS Release 14.2, you can configure the delta-export
statement at the [edit system commit] hierarchy level to reduce the time taken to
commit configuration changes.
[See commit (system) and delta-export.]
VPNs
•
EVPN (EX9200)—Starting with Junos OS Release 14.2, an Ethernet virtual private
network (EVPN) is made up of a set of CE devices that are connected to PE devices
or MPLS edge switches (MES) that comprise the edge of the MPLS network. The CE
devices could be routers or switches. The MESs provide Layer 2 virtual bridge
connectivity between the CE devices. You can deploy multiple EVPNs in the provider's
network. In an EVPN, learning between MESs takes place in the control plane by using
BGP rather than in the data plane (as is the case with traditional bridging). EVPNs can
be used to provide connectivity between data centers spanning metropolitan area
networks (MANs) and wide area networks (WANs).
[See EVPN Overview for Switches.]
10
Changes in Behavior and Syntax
VXLAN
•
VXLAN Gateway support (EX9200)—EX9200 switches now support Virtual Extensible
LAN (VXLAN) gateways. Each VXLAN gateway supports the following functionalities:
•
32,000 VXLANs (with one VXLAN per bridge domain)
•
8,000 virtual tunnel endpoints (VTEPs)
•
32,000 multicast groups
•
Switching functionality with traditional Layer 2 networks and VPLS networks
•
Inter-VXLAN routing and VXLAN-only bridging
•
Virtual switches
•
Virtual routing instances
•
Configurable load balancing
•
Statistics for remote VTEPs
[See Understanding VXLANs.]
Related
Documentation
•
•
•
•
•
•
This section lists the changes in behavior of Junos OS features and changes in the syntax
of Junos OS statements and commands from Junos OS Release 14.2R1 for the EX Series.
•
Interfaces and Chassis
•
11
•
Command to correct mismatches between MAC and ARP entries in MC-LAGs
(EX9200)—Starting with Junos OS Release 14.2, the arp-l2-validate command is
introduced as a workaround for issues related to MAC and ARP entries going out of
sync in an MC-LAG scenario. Use the command to correct mismatches between MAC
and ARP entries related to the next-hop interface.
Related
Documentation
•
Changed destination file format for transfer-on-commit feature (EX9200)—Starting
with Junos OS Release 14.2, the format of the destination filename for the
transfer-on-commit feature is changed from
router-name_juniper.conf.n.gz_YYYYMMDD_HHMMSS to
router-name_YYYYMMDD_HHMMSS_juniper.conf.n.gz.
•
•
•
•
•
•
Known Behavior
This section lists known behavior, system maximums, and limitations in hardware and
software in Junos OS Release 14.2R1 for the EX Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
OpenFlow
OpenFlow
12
•
On EX9200 switches running OpenFlow v1.3.1, the output for the show openflow flows
command displays IPv6-related fields. However, the Junos OS implementation of
OpenFlow v1.3.1 for EX9200 switches does not currently support IPv6 specifications.
Therefore, the output for these fields typically displays None.
•
On EX9200 switches, after a restart of the firewall filter daemon, an OpenFlow 1.3.1
packet might not be received on an interface. PR969520
•
On EX9200 switches running OpenFlow v1.3.1, flow statistics show that the packet
flow is increasing even when the output port link is down. PR987753
Known Issues
Related
Documentation
•
On EX9200 switches running OpenFlow v1.3.1, ADPC line cards are not supported.
Configure enhanced IP network services mode to disable ADPC line cards. PR988256
•
On EX9200 switches running OpenFlow v1.3.1, EtherType 0x806 (ARP) and IPv4
address fields are not supported as match fields. PR990196
•
•
•
•
•
•
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R1
for the EX Series.
•
Open vSwitch Database (OVSDB) Management Protocol
•
OpenFlow
•
Platform and Infrastructure
•
•
VXLAN
Open vSwitch Database (OVSDB) Management Protocol
•
The amount of time that it takes for Juniper Networks devices that function as hardware
virtual tunnel endpoints (VTEPs) to learn a new MAC address after the first packet is
sent from this MAC address is a maximum of 4.5 seconds. (The amount of time depends
upon the server configuration on which VMware NSX is running.) During this time, traffic
destined for this MAC address is flooded into the VXLAN. PR962945
•
After the connections with NSX controllers are disabled on a Juniper Networks device,
interfaces that were configured to be managed by OVSDB continue to transmit traffic.
PR980577
•
An entity with a particular MAC address is moved from one Juniper Networks device
so that its traffic is handled by a different Juniper Networks device that functions as a
hardware virtual tunnel endpoint (VTEP). This MAC address is not learned by entities
served by the new hardware VTEP until the hardware VTEP that previously handled
its traffic ages out from the MAC address. During this transitional period, traffic destined
for this MAC address is dropped. PR988270
13
OpenFlow
•
On EX9200 switches running OpenFlow v1.3.1, restarting the FPC might terminate the
DFWD process and create a core file. This will require a restart of the OpenFlow daemon
for the OpenFlow functionality to work properly. PR842923
•
On a hybrid interface on EX9200 switches running OpenFlow v1.3.1, OpenFlow traffic
can exit only a logical interface that has the same VLAN-ID range as that of the ingress
interface. PR865320
•
On EX9200 switches running OpenFlow v1.3.1, a BGP session might flap when an
OpenFlow interface is receiving line-rate traffic and the traffic is not matching any rule,
and therefore the default action of packet-in is applied. PR892310
•
On EX9200 switches running OpenFlow v1.3.1, topology discovery might fail when an
LLDP packet-in message is sent to the controller at a traffic rate of 1 Mbps. PR897917
•
On EX9200 switches running OpenFlow v1.3.1, if OpenFlow is enabled when you query
port information, the values for duration_nsec and duration_sec will always be 0.
PR978321
•
On EX9200 switches running OpenFlow v1.3.1, the switching device does not respond
when an interface goes down if the echo interval timeout is set to less than 11 seconds.
PR989308
•
On EX9200 switches, when apply-groups is used in the configuration, the expansion
of interfaces <*> apply-groups is done against all interfaces during the configuration
validation process, even if apply-groups is configured only under a specific interface
stanza. This issue does not affect the configuration; if the configuration validation
passes, apply-groups is expanded only on interfaces for which apply-groups is
configured. PR967233
•
On EX9200 switches, all interfaces on 1-Gigabit line cards with copper SFP will flap
during ISSU. The unused ports will flap as well. One or more interfaces might flap on
a 10-Gigabit line card with 32 ports in an MC-LAG/LAPC configuration. PR1007038
VXLAN
14
•
On EX9200 switches, IGMP snooping does not work on VTEP interfaces. PR989664
•
On EX9200 switches, IRB interfaces do not join VXLAN-tunnel multicast groups and
remain in Down state if there are no local Layer 2 interfaces configured as part of the
VLAN. PR991580
•
On EX9200 switches, multicast traffic might be dropped for intervals of 40 through
45 seconds during a Routing Engine switchover performed using the CLI command
request chassis routing-engine master switch. PR998924
Documentation Updates
Related
Documentation
•
•
•
•
•
•
There are no errata or changes in Junos OS Release 14.2R1 for the EX Series switches
documentation.
Related
Documentation
•
•
•
•
•
•
Migration, Upgrade, and Downgrade Instructions
This section contains the upgrade and downgrade policies for Junos OS for the EX Series.
Upgrading or downgrading Junos OS can take several hours, depending on the size and
configuration of the network.
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 15
Upgrade and Downgrade Support Policy for Junos OS Releases
Support for upgrades and downgrades that span more than three Junos OS releases at
a time is not provided, except for releases that are designated as Extended End-of-Life
(EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can
upgrade directly from one EEOL release to the next EEOL release, even though EEOL
releases generally occur in increments beyond three releases.
You can upgrade or downgrade to the EEOL release that occurs directly before or after
the currently installed EEOL release, or to two EEOL releases earlier or later. For example,
Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from Junos OS
Release 10.0 to Release 10.4 or even from Junos OS Release 10.0 to Release 11.4. However,
you cannot upgrade directly from a non-EEOL release that is more than three releases
ahead or behind. For example, you cannot directly upgrade from Junos OS Release 10.3
(a non-EEOL release) to Junos OS Release 11.4 or directly downgrade from Junos OS
Release 11.4 to Junos OS Release 10.3.
15
To upgrade or downgrade from a non-EEOL release to a release more than three releases
earlier or later, first upgrade to the next EEOL release and then upgrade or downgrade
from that EEOL release to your target release.
For more information about EEOL releases and to review a list of EEOL releases, see
http://www.juniper.net/support/eol/junos.html .
For information on software installation and upgrade, see the Installation and Upgrade
Guide.
Related
Documentation
•
•
•
•
•
•
Product Compatibility
•
Software Compatibility on page 16
•
Hardware Compatibility on page 16
Software Compatibility
The Juniper Networks implementation of the Open vSwitch Database (OVSDB)
management protocol on the EX9200 switch is supported with VMware NSX version
4.0.3.
Hardware Compatibility
To obtain information about the components that are supported on the devices, and
special compatibility guidelines with the release, see the Hardware Guide for the product.
To determine the features supported on EX Series switches in this release, use the Juniper
Networks Feature Explorer, a Web-based application that helps you to explore and
compare Junos OS feature information to find the right software release and hardware
platform for your network. Find Feature Explorer at:
http://pathfinder.juniper.net/feature-explorer/
Related
Documentation
16
•
•
•
•
•
•
Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, and T Series Core Routers
Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal
Edge Routers, and T Series Core Routers
These release notes accompany Junos OS Release 14.2R1 for the M Series, MX Series,
and T Series. They describe new and changed features, limitations, and known and
resolved problems in the hardware and software.
webpage, located at http://www.juniper.net/techpubs/software/junos/.
CAUTION: This release introduces some behavior changes to the unified
in-service software upgrade (ISSU) functionality for M Series, MX Series, and
T Series routers. We do not recommend using unified ISSU to upgrade from
an earlier Junos OS release to Junos OS 14.2R1.
•
•
•
•
•
•
•
OS Release 14.2R1 for the M Series, MX Series, and T Series.
•
Hardware on page 18
•
Authentication, Authorization, and Accounting (AAA) (RADIUS) on page 19
•
Class of Service (CoS) on page 19
•
General Routing on page 20
•
High Availability (HA) and Resiliency on page 20
•
Interfaces and Chassis on page 21
•
IPv6 on page 28
•
Layer 2 Features on page 28
•
Management on page 29
•
MPLS on page 29
•
Multicast on page 30
•
Network Management and Monitoring on page 31
•
Operation, Administration, and Maintenance (OAM) on page 33
•
Platform and Infrastructure on page 33
17
•
Routing Policy and Firewall Filters on page 33
•
Routing Protocols on page 34
•
Services Applications on page 35
•
Software-Defined Networking (SDN) on page 36
•
Subscriber Management and Services on page 37
•
User Interface and Configuration on page 39
•
VPNs on page 39
Hardware
SFPP-10G-DT-ZRC2 (MX Series)—Starting in Junos OS Release 14.2, the
SFPP-10G-DT-ZRC2 tunable transceiver provides a duplex 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
Juniper Networks specifications. The SFPP-10G-DT-ZRC2 transceiver supports WAN-PHY
and LAN-PHY modes. To configure the wavelength on the transceiver, use the wavelength
statement at the [edit interfaces interface-name optics-options] hierarchy level.
The following interface modules support the SFPP-10G-DT-ZRC2 transceiver:
MX Series MPCs and MICs:
•
10-Gigabit Ethernet MIC with SFP+ (model number: MIC3-3D-10XGE-SFPP)—Supported
in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1R1, and later
•
16-port 10-Gigabit Ethernet MPC (model number: MPC-3D-16XGE-SFPP)—Supported
in Junos OS Release 12.3R8, 13.2R5, 13.3R3, 14.1R2, 14.2, and later
•
32-port 10-Gigabit Ethernet MPC4E (model number:
MPC4E-3D-32XGE-SFPP)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2,
14.1R1, and later
•
2-port 100-Gigabit Ethernet + 8-port 10-Gigabit Ethernet MPC4E (model number:
MPC4E-3D-2CGE-8XGE)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1R1,
and later
For more information about interface modules, see the “Cables and Connectors” section
in the Interface Module Reference for your router.
[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications, MX Series Interface
Module Reference, and wavelength.]
18
Authentication, Authorization, and Accounting (AAA) (RADIUS)
•
RADIUS functionality over IPv6 for system AAA—Starting in Release 14.2, Junos OS
supports RADIUS functionality over IPv6 for system AAA (authentication, authorization,
and accounting) in addition to the existing RADIUS functionality over IPv4 for system
AAA. With this feature, Junos OS users can log in to the router authenticated through
RADIUS over an IPv6 network. Thus, Junos OS users can now configure both IPv4 and
IPv6 RADIUS servers for AAA. To accept the IPv6 source address, include the
source-address-inet6 statement at the [edit system radius-server ipv6] hierarchy level.
(If an IPv6 RADIUS server is configured without any source-address-inet6, default ::0
is used as the source address.)
[See Configuring RADIUS Authentication, and Configuring RADIUS System Accounting.]
Class of Service (CoS)
•
Support for user-configurable traffic class map (T4000 routers with Type 5 FPC)—
Junos OS Release 14.2 introduces a user-configurable input priority map, known as a
traffic class map, that helps prioritize and classify input traffic entering a Packet
Forwarding Engine during ingress oversubscription. You can define traffic class maps
for a packet on the basis of the following CoS code points:
•
Differentiated Services code point (DSCP) for IP DiffServ
•
IP precedence bits
•
MPLS EXP bits
•
IEEE 802.1p CoS bits
•
IEEE-802.1ad drop eligible indicator (DEI) bits
You can associate the traffic class map to one of the following traffic classes:
•
Real time
•
Network control
•
Best effort
[See Configuring Traffic Class Maps.]
•
Source class accounting (T4000)—Starting with Junos OS Release 14.2, the source
class accounting is performed at the ingress on a T4000 Type 5 FPC in T4000 routers.
[See Understanding Source Class Usage and Destination Class Usage Options.]
•
Increased per-VC bandwidth speed on ATM MIC with SFP (MX Series with MPCs
and ATM MIC with SFP)—Starting in Junos OS Release 14.2, you can configure constant
bit rate (CBR) bandwith speeds up to 622 Mbps (OC12) per virtual circuit (VC) on an
MX Series router with an ATM MIC with SFP (model number MIC-3D-8OC3-2OC12-ATM)
and a supported MPC installed. In earlier Junos OS releases, you could configure per-VC
CBR bandwidth speeds only up to 155 Mbps (OC3) on an ATM MIC with SFP.
19
With the increased per-VC CBR bandwidth speed, each VC can support up to line rate
traffic in OC12 mode, subject to the following restrictions:
•
You must configure the CBR service category when you define the ATM traffic shaping
and scheduling profile.
For other ATM service categories including variable bit rate nonreal time (VBR-NRT),
variable bit rate real time (VBR-RT), and unspecified bit rate (UBR), the per-VC
bandwidth speed for an ATM MIC with SFP remains a maximum of 155 Mbps.
•
The actual Layer 3 payload throughput you obtain depends on the ATM encapsulation
type and IP packet size you use.
[See CoS on Circuit Emulation ATM MICs Overview.]
General Routing
•
Configurable TCP MSS Value—Starting in Junos OS Release 14.2, you can configure
the TCP MSS value on MX Series routers. To specify a TCP MSS value on MX Series
routers, include the tcp-mss statement at the [edit interfaces interface-name unit
logical-unit-number family family] hierarchy level.
•
Configuring routing process mode (MX Series)— Starting in Junos OS Release 14.2,
you can configure routing process mode to 64-bit mode or 32-bit mode.
[See routing.]
High Availability (HA) and Resiliency
•
Support for Ethernet alarm indication signal (MX Series)—Starting with Junos OS
Release 14.2, ITU-T Y.1731 Ethernet alarm indication signal function (ETH-AIS) is
supported on MX Series routers. ETH-AIS provides fault management for service
providers where it enables the service provider to suppress alarms when a fault condition
is detected. Using ETH-AIS, you can differentiate faults at the customer level and faults
at the provider level. When a fault condition is detected, a maintenance end point
(MEP) generates and transmits ETH-AIS packets to the configured router for a specified
duration until the fault condition is cleared. An MEP that is configured to generate
ETH-AIS packets transmits the signals to a level higher than its own. Therefore, the
MEP receiving ETH-AIS packets recognizes that the fault is at a lower level and
suppresses alarms at its own level.
MX Series routers support ETH-AIS protocol data unit (PDU) generation for server
MEPs on the basis of the following defect conditions:
•
Loss of connectivity (physical link loss detection)
•
Layer 2 circuit or Layer 2 VPN down
[See Ethernet Alarm Indication Signal (ETH-AIS) Function Overview.]
•
20
MX Series Virtual Chassis support for logical systems (MX Series with
MPCs)—Starting in Junos OS Release 14.2, MX Series Virtual Chassis configurations
support the use of logical systems. A logical system independently performs a subset
of the tasks performed by the main router and has a unique routing table, and unique
interfaces, policies, and routing instances. In earlier Junos OS releases, MX Series Virtual
Chassis configurations do not support the logical systems feature.
To configure routing policies or enable a protocol such as OSPF when you are using
logical systems with an MX Series Virtual Chassis, you must include routing policy
configuration statements at the [edit logical-systems logical-system-name
policy-options] hierarchy level, and protocol configuration statements at the [edit
logical-systems logical-system-name protocols] hierarchy level.
[See Introduction to Logical Systems.]
•
MX Series Virtual Chassis support on MS-MPCs (MX Series with MS-MPCs)—Starting
in Junos OS Release 14.2, you can configure a two-member MX Series Virtual Chassis
to use the stateful firewall advanced service on MX240, MX480, or MX960 routers
with Multiservices MPCs (MS-MPCs) and Multiservices MICs (MS-MICs) installed. A
two-member MX Series Virtual Chassis configuration supports a maximum of four
MS-MPCs and four MS-MICs per Virtual Chassis.
In earlier Junos OS releases, MX240, MX480, and MX960 routers did not support
MS-MPCs or MS-MICs in MX Series Virtual Chassis configurations.
•
Support for inline active flow monitoring (T4000 routers with
T4000-FPC5-3D)—Beginning with Release 14.2, Junos OS supports inline active flow
monitoring services on T4000 routers with T4000-FPC5-3D. Inline active flow
monitoring is implemented on the Packet Forwarding Engine. Inline active flow
monitoring supports version 9 and IPFIX flow collection templates.
[See Configuring Inline Active flow Monitoring.]
•
New command to set the license mode for MPCs (MX240, MX480, MX960, MX2010
and MX2020)—Starting with Junos OS Release 14.2, you can set the license mode for
enhanced MPCs such as MPC4E, MPC5E, and MPC6E by including the ir-mode
configuration statement at the [edit chassis fpc] hierarchy level. Setting the license
mode enables you to distinguish between an MPC with an IR license and an MPC with
an R license after the MPC is installed on the router.
NOTE: You cannot set or alter the license of the MPC when you configure
the mode. The license mode settings are used only to provide information.
The license mode settings are set per slot. If the MPC is installed on a different slot, or
moved to another device, the license mode settings must be re-configured on the new
slot or device. Also, the license mode settings configured on the previous slot must be
removed. To view the current license mode settings, as well as the effect of the new
settings, use the show chassis fpc and show chassis hardware extensive commands.
To delete the license mode settings, use the delete chassis fpc command.
•
Supported for mixed-mode aggregated Ethernet (MX Series)—Starting with Junos
OS Release 14.2, support for mixed aggregated Ethernet bundles is extended to MX240,
MX480, MX960, MX2010, and MX2020 routers, thereby enabling you to configure the
21
MPC-based member links with any combination of rates—10-Gigabit Ethernet,
40-Gigabit Ethernet, and 100-Gigabit Ethernet—on an aggregated Ethernet interface.
[See Understanding Mixed Rates and Mixed Modes on Aggregated Ethernet Bundles.]
•
Support for MPC5E on SCBE2 (MX Series)—Starting with Junos OS Release 14.2,
MPC5E is supported on SCBE2 on the MX240, MX480, and MX960.
•
Entropy label support in mixed mode (MX Series)—Beginning with Junos OS Release
14.2, the entropy label is supported in mixed mode for chassis. MX Series 3D Universal
Edge Router DPCs support the pop out entropy label but do not support the flow label.
The entropy label can be configured without enhanced-ip configuration.
•
Support for Private VLAN (MX240, MX480, and MX960)—Starting with Junos OS
Release 14.2, you can configure a private VLAN on a single MX Series router to span
multiple MX Series routers. VLANs limit broadcasts to specified users. Private VLANs
take this concept a step further by limiting communication within the VLAN. Private
VLANs accomplish this limitation by restricting traffic flows through their member
switch ports (which are called “private ports”) so that these ports communicate only
with a specified uplink trunk port or with specified ports within the same VLAN. The
uplink trunk port (or link aggregation group or LAG) is usually connected to a router,
firewall, server, or provider network. Each Private VLAN typically contains many private
ports that communicate only with a single uplink, thereby preventing the ports from
communicating with each other. Private VLANs provide Layer 2 isolation between ports
within the same VLAN, splitting a broadcast domain into multiple isolated broadcast
subdomains and essentially putting secondary VLANs inside another primary VLAN.
You can configure an isolated VLAN within a private VLAN that spans multiple switches
by including the isolated-vlan vlan-id statement at the [edit bridge-domains
bridge-domain-name] hierarchy level. You configure an interface to be the trunk port,
connecting routers that are configured with a Private VLAN across these routers by
including the interface-mode trunk inter-switch-link statement at the [edit interfaces
ethernet-interface-name unit logical-unit-number family bridge] hierarchy level. The
Private VLANtrunk port is a member of all the VLANs within the Private VLAN (that is,
the primary VLAN, the community VLANs, and the interswitch isolated VLAN). It can
communicate with all ports other than the isolated ports. Configure a community
VLAN, which is a secondary VLAN that transports frames among community interfaces
within the same community and forwards frames upstream to the primary VLAN, by
specifying a list of VLAN IDs separated by spaces by including the community-vlan
vlan-ids statement at the [edit bridge-domains bridge-domain-name] hierarchy level.
This functionality is supported only on MX240, MX480, and MX960 routers that function
in enhanced LAN mode (by entering the network-services lan statement at the [edit
chassis] hierarchy level).
•
22
Port-based network access control (MX240, MX480, and MX960)—Starting in Junos
OS Release 14.1, support is implemented for controlling access to your network through
an MX Series router by using several different authentication methods, by configuring
802.1X, MAC RADIUS, or a captive portal. This functionality is supported on an MX
Series Virtual Chassis combination that functions in enhanced LAN mode (by entering
the network-services lan statement at the [edit chassis] hierarchy level). Port-based
network access control is supported on MX240, MX480, and MX960 routers with MPCs
in both the MX-LAN mode and the non-MX-LAN mode (with other supported network
services modes on MPCs on these routers). To configure the IEEE 802.1x Port-Based
Network Access Control protocol on Ethernet interfaces, you must configure the
authenticator statement at the [edit protocols authentication-access-control] hierarchy
level. You can also configure captive portal authentication on a router so that users
connected to the switch are authenticated before being allowed to access the network.
You can also configure Junos Pulse Access Control Service as the access policy to
authenticate and authorize users connected to the switch for admission to the network
and for access to protected network resources by using the uac-policy statement.
•
MAC RADIUS authentication (MX Series routers with DPCs and MPCs)—Starting in
Junos OS Release 14.2, on MX Series routers with MPCs and DPCs, you can permit
devices that are not 802.1X-enabled LAN access by configuring MAC RADIUS
authentication on the MX Series router interfaces to which the hosts are connected.
You can also allow non-802.1X-enabled devices to access the LAN by configuring their
MAC address for static MAC bypass of authentication. You can configure MAC RADIUS
authentication on an interface that also allows 802.1X authentication, or you can
configure either authentication method alone. Include the mac-radius flap-on-disconnect
statement at the [edit protocols dot1x authenticator interface interface-name] hierarchy
level to cause the router to reset the interface on which the supplicant is authenticated
when the RADIUS server sends a disconnect message to a supplicant. If the interface
is configured for multiple supplicant mode, the switch resets all the supplicants on the
specified interface. This option takes effect only when the restrict option is also set.
To restrict authentication to MAC RADIUS only, include the mac-radius restrict
statement at the [edit protocols dot1x authenticator interface interface-name] hierarchy
level. In restrictive mode, all 802.1X packets are eliminated and the attached device
on the interface is considered a nonresponsive host.
If both MAC RADIUS and 802.1X authentication are enabled on the interface, the switch
first sends the host three EAPOL requests to the host. If there is no response from the
host, the switch sends the host’s MAC address to the RADIUS server to check whether
it is a permitted MAC address. If the MAC address is configured as permitted on the
RADIUS server, the RADIUS server sends a message to the switch that the MAC address
is a permitted address, and the switch opens LAN access to the nonresponsive host
on the interface to which it is connected.
•
Support for fabric black-hole detection and recovery (TX Matrix Plus)—Starting in
Junos OS Release 14.2, TX Matrix Plus routers can detect and recover from fabric faults
that are not caused by hardware failure.
To recover from a fabric black-hole condition, the routing matrix uses the following
options:
•
SFC SIB Reboot
•
LCC SIB Reboot
•
FPC Reboot
•
Destination Reprogramming
•
Interchassis Link Retraining
23
You can disable the automatic recovery feature by using the auto-recovery-disable
statement at the [edit chassis fabric degraded] hierarchy level. You can also turn the
FPC offline by using the fpc-offline-on-blackholing statement at the [edit chassis fabric
degraded] hierarchy level if nonrecoverable errors are present in the routing matrix.
[See fpc-offline-on-blackholing and auto-recovery-disable.]
•
Support for inclusion of element IDs 54 and 64 in IPFIX templates (MX
Series)—Starting with Junos OS Release 14.2, the following attributes can be contained
in IPFIX flow templates that are sent to the flow collector:
•
fragmentIdentification (element ID 54)
•
ipv6ExtensionHeaders (element ID 64)
To enable the inclusion of element ID 54, fragmentIdentification, and element ID 64,
ipv6ExtensionHeaders, in IPFIX flow templates that are exported to the flow collector,
include the ipv6-extended-attrib statement at the [edit chassis fpc slot-number
inline-services flow-table-size] hierarchy level. Collection of IPv4 fragmentation IDs
occurs automatically without having to configure this setting explicitly.
•
Enhanced Y.1731 functionality on VPWS to support ETH-LM for dual VLAN tags (MX
Series)–Junos OS supports Ethernet frame loss measurement (ETH-LM) between
maintenance association end points (MEPs) configured on Ethernet physical or logical
interfaces on Rev-B Dense Port Concentrators (DPCs) in MX Series routers. Additionally,
the Y.1731 functionality supports ETH-LM only for an end-to-end connection that uses
Virtual Private Wire Service (VPWS). Prior to Junos OS Release 14.2, this functionality
did not support ETH-LM for dual VLAN identifier tags. It only supported ETH-LM for
untagged or single VLAN identifier tags. Starting with Junos OS Release 14.2, the Y.1731
functionality supports ETH-LM on VPWS for dual VLAN identifier tags as well.
•
Support for enhanced link aggregation group on (MX Series routers with
MPCs)—Starting in Junos OS Release 14.2, you can configure an enhanced link
aggregation group (LAG) on MX Series routers. When you associate a physical interface
with an aggregated Ethernet interface, the physical child links are also associated with
the parent aggregated Ethernet interface to form a LAG.
In the absence of enhanced LAG support, one child next hop is created for each member
link of an aggregated Ethernet interface for each VLAN interface. For example, an
aggregate next hop for an aggregated Ethernet interface with 16 member links leads
to the installation of 17 next hops per VLAN created. Thus the number of next hops
supported on the routers with aggregated Ethernet interfaces is significantly reduced.
With the enhanced LAG support, when the set chassis network-services enhanced-ip
statement is configured, child next hops are not created for member links and, as a
result, a higher number of next hops can be supported.
•
24
Support for physical interface damping (M Series and MX Series )—Beginning with
Junos OS 14.2, interface damping is supported on physical interfaces to address longer
periodic flapping lasting 5 seconds or more, with an up and down duration of one
second. This damping method limits the number of advertisements of longer interface
up and down events to the upper-level protocols. For longer periodic interface flaps,
configure interface damping with the damping statement at the [edit interfaces
interface-name] hierarchy level. You use the show interfaces extensive command to
view the interface damping values and link state.
[See Damping Longer Physical Interface Transitions.]
•
Ethernet ring protection switching (MX Series)—Starting with Junos OS Release 14.2,
MX Series routers support Ethernet ring protection switching (ERPS) which is defined
in ITU-T Recommendation G.8032/Y.1344 version 2. ERPS comprises the following
features:
•
G.8032/Y.1344 version 2 compliant protocol state-machine with the new FDB flush
mechanism
•
Support for revertive and nonrevertive mode of operation of the Ethernet ring
•
Support for manual commands such as manual switch, force switch, and clear
commands
•
Support for configurable wait-to-restore, wait-to-block, and guard timers
•
Support for multiple logical ring instances on the same physical ring
•
Support for ring interconnection using non-virtual-channel mode. Ring interconnection
using virtual channel mode is not supported.
•
Support for ring ID values from 1 through 239
•
Support for ring protection link neighbor node
•
Support for topology change propagation from a sub-ring to an interconnected major
ring
•
Ability to add a node or remove a node from the Ethernet ring
[See Understanding Ethernet Ring Protection Switching Functionality.]
•
MS-MIC support (MX104)—In Junos OS Release 14.2 and later releases, the
Multiservices MIC (MS-MIC-16G) is supported on MX104 3D Universal Edge Routers.
The MS-MIC has an enhanced memory of 16 GB and provides improved scaling and
high performance. The MX104 chassis is capable of supporting two MS-MICs.
The MS-MIC supports the following software features:
•
Active flow monitoring exports flow monitoring version 9 records, based on RFC
3954
•
IPsec encryption
•
Network Address Translation (NAT) for IP addresses
•
Port Address Translation (PAT) for port numbers
•
Real-time performance monitoring
•
Stateful firewall with packet inspection which detects SYN attacks, ICMP and UDP
floods, and ping-of-death attacks
•
Traffic sampling
[See Multiservices MIC.]
25
•
Support for hold-off timing synchronization (MX Series)—Starting in Junos OS Release
14.2, you can configure hold-off time for Synchronous Ethernet interfaces and external
clock synchronization sources to prevent rapid successive switching. If an interface
goes down, hold-off time delays short signal failures from being sent to the clock
selection process.
If you configure hold-off time when quality level (QL) mode is enabled, the configured
quality level is used in the clock selection process during the hold-off time period. After
the hold-off time period ends, a signal failure is sent to the clock selection process.
To configure hold-off time, include the hold-off-time statement at the [set chassis
synchronization source interfaces (external-a | external-b | interface interface-name)]
hierarchy level.
[See Understanding Clock Synchronization on MX Series Routers]
•
Support for Synchronous Ethernet on MPC5E and MPC6E (MX240, MX480, MX960,
MX2010, and MX2020)—Junos OS Release 14.2 extends Synchronous Ethernet support
to MPC5E and MPC6E on the MX240, MX480, MX960, MX2010, and MX2020 routers.
MPC5E-40G10G, MPC5EQ-40G10G, MPC5E-100G10G, MPC5EQ-100G10G, and
MX2K-MPC6E support Ethernet Synchronization Messaging Channel (ESMC) and
external clocking.
To configure Synchronous Ethernet, include the synchronization statement and its
substatements at the [edit chassis] hierarchy level.
•
Support for REST interfaces (M Series, MX Series, and T Series)— Starting with Junos
OS Release 14.2, M Series, MX Series, and T Series routers support REST interfaces for
secure connection to Junos OS devices and execution of remote procedure calls, a
REST API Explorer GUI enabling you to conveniently experiment with any of the REST
APIs, and a variety of formatting and display options, including JSON support.
[See REST API Guide.]
•
Aggregated Ethernet-specific naming for logical systems—Starting in Junos OS
Release 14.2, aggregated Ethernet interfaces created under a logical system can be
individually named. Prior to Release 14.2, aggregated Ethernet interfaces were named
automatically, AE1, AE2, and so on, upon setting the device count, and system resources
were allocated for each aggregated Ethernet interface regardless of whether it was
used or not. This change allows administrators to use whatever naming scheme makes
sense in the context of their deployment and is more efficient in the allocation of system
resources.
•
Increase available bandwidth by bypassing the queuing chip (MX240, MX480,
MX960, MX2010, MX2020)—On MPC1 Q, MPC1E Q, MPC2 Q, MPC2 EQ, MPC2E Q,
MPC2E EQ, and MPC5E Q line cards, with Junos OS Release 14.2 or later, when
hierarchical and per-VLAN queuing features are not required, you can bypass the
queuing chip to increase the available bandwidth on an interface. You can bypass the
queuing chip by enabling the bypass-queuing-chip statement at the [edit interfaces
interface-name] hierarchy level.
[See Increase Available Bandwidth on Rich-Queuing MPCs by Bypassing the Queuing
Chip.]
26
•
Configuration support to keep an MC-LAG aggregated Ethernet link up for a peer
with limited LACP capability—Starting with Junos OS Release 14.2, you can configure
an aggregated Ethernet link or interface in an MC-LAG topology to remain up even
when the peer link or peer interface has limited Link Access Control Protocol (LACP)
capability.
To configure this feature, configure the force-up statement at the [edit interfaces
interface-name aggregated-ether-options lacp] hierarchy level.
•
Load balancing for ECMP next hops (MX Series)—Starting with Junos OS Release
14.2, the following load-balancing solutions are supported on equal-cost multipath
(ECMP) next-hops to correct traffic imbalance among the member links:
•
Adaptive — Uses real-time feedback and control mechanism to monitor and manage
traffic imbalances.
•
Random spray — Packet random spray load balancing randomly sprays the packets
to the aggregate next hops to ensure that the next hops are equally loaded.
To configure adaptive load balancing use the ecmp-alb statement at the [edit chassis]
hierarchy level. However, to configure adaptive load balancing, make sure that the
per-packet statement is enabled at the [edit policy-options policy-statement policy_name
then load-balance] hierarchy level. To configure random load balancing, use the random
statement at the [edit policy-options policy-statement policy_name then load-balance]
hierarchy level.
•
Enhanced Y.1731 functionality on VPWS to support ETH-LM for dual VLAN tags (MX
Series)–Junos OS supports Ethernet frame loss measurement (ETH-LM) between
maintenance association end points (MEPs) configured on Ethernet physical or logical
interfaces on Enhanced Dense Port Concentrators (DPCEs) in MX Series routers. The
Y.1731 functionality supports ETH-LM only for an end-to-end connection that uses
Virtual Private Wire Service (VPWS). In releases before Release 14.2, Junos OS supports
ETH-LM only for untagged or single-tagged VLAN identifiers. Starting with Junos OS
Release 14.2, ETH-LM is supported on VPWS for dual VLAN identifier tags as well.
[See Ethernet Frame Loss Measurement Overview.]
•
Support for interface damping for longer periodic interface flaps (MX960, MX480,
MX240, MX80 3D Universal Edge Routers and M10i Multiservice Edge
Routers)—Starting with Junos OS Release 14.2, interface damping is supported on
physical interfaces to address longer periodic flapping lasting five seconds or more,
with an up and down duration of one second. This damping method limits the number
of advertisements of longer interface up and down events to the upper-level protocols.
For longer periodic interface flaps, configure interface damping by using the damping
statement at the [edit interfaces interface-name] hierarchy level. You use the show
interfaces extensive command to view the interface damping values and link state.
[See Damping Longer Physical Interface Transitions]
27
IPv6
•
IPv6 support for next-hop groups (MX Series)— Starting in Junos OS Release 14.2,
this feature allows support of next-hop groups of type inet6 (IPv6). The following
features are also supported:
•
Configuration of interfaces of inet6 (IPv6) type at the [edit forwarding-options
port-mirroring family inet6 output] hierarchy level or subgroups at the [edit
forwarding-options port-mirroring family inet6 output next-hop-group] hierarchy level.
•
Configuration of next-hop groups as filter action.
•
Configuration of next-hop groups as port-mirror destination when specified at the
[edit forwarding-options port-mirroring family inet6 output] hierarchy level.
[See next-hop-group, port-mirroring, and [edit firewall] Hierarchy Level.]
Layer 2 Features
•
Egress protection service mirroring for BGP-signaled Layer 2 service (MX Series)—
Starting in Junos OS Release 14.2, this feature enables BGP-signaled multihomed l2vpn
to restore egress traffic in the following scenarios:
•
PE to CE link failure
•
Egress PE node failure
[See Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services,
Example: Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services,
and host-standby.]
•
Create multiple pseudowires on a per-virtual circuit basis (MX Series)—Starting in
Junos OS Release 14.2, you can create multiple pseudowires between the same pair
of PEs in LDP-VPLS for a single routing instance, using the same loopback address.
Do this with the vpls-id-list option under LDP-VPLS neighbor. For each pseudowire
created under a neighbor, VPLS creates a VT/LSI interface and adds both it and the
label route to the mpls.0 table. Each pseudowire terminates in its specified mesh-group.
Support is added at the following CLI hierarchy level: [edit routing-instances
routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address
pseudowire-status-tlv vpls-id-list vc-id-numbers 1-4294967295]. For more information,
see the vpls-id-list command reference.
•
28
Native Analyzer Support (MX240, MX480 and MX960)—Starting with Junos OS
Release 14.2, native analyzers and remote port-mirroring capabilities. A native analyzer
configuration contains both an input stanza and an output stanza in the analyzer
hierarchy for mirroring packets. In remote port mirroring, the mirrored traffic is flooded
into a remote mirroring VLAN that can be specifically created for the purpose of receiving
mirrored traffic. The analyzer configuration is available at the [edit forwarding-options
analyzer] hierarchy level.
Management
•
YANG module that defines the Junos OS configuration hierarchy—Starting with Junos
OS Release 14.2, Juniper Networks provides a YANG module that defines the Junos OS
configuration hierarchy. You can download the YANG module that defines the complete
Junos OS configuration hierarchy for all devices running that Junos OS release from
the Juniper Networks website at http://www.juniper.net/. You can also generate a YANG
module that defines the device-specific configuration hierarchy by using the show
system schema module configuration format yang operational mode command on the
local device. The Juniper Networks YANG module, configuration, is bound to the
namespace URI http://yang.juniper.net/yang/1.1/jc and uses the prefix jc.
MPLS
•
On-demand packet loss and delay measurement (MX Series routers with MPCs and
MICs only)—Junos OS Release 14.2 introduces an on-demand tool to monitor and
measure packet loss, packet delay, or both for associated bidirectional MPLS ultimate
hop popping (UHP) point-to-point label-switched paths (LSPs), using the monitor
mpls loss rsvp, monitor mpls delay rsvp, and monitor mpls loss-delay rsvp commands,
respectively.
These commands provide an on-demand summary of performance metrics for direct
mode packet loss, two-way packet delay, and related metrics, such as inter-packet
delay variation and channel throughput measurement.
This functionality provides real-time visibility into network performance, thereby
facilitating network performance planning, troubleshooting, and evaluation.
•
GMPLS RSVP-TE VLAN LSP signaling (M Series, MX Series, and T Series)—Starting
with Junos OS Release 14.2, the point-to-point Layer 2 connectivity between two client
routers across an external or third-party server-layer network can be set up by the
client routers on an on-demand basis using GMPLS RSVP-TE signaling. This feature
provides the client routers the flexibility to establish, maintain, and provision each
individual Layer 2 connection, without any dependency on the server-layer
administration. As a result, the burden on the operational expenses of the provider
network, in terms of provisioning individual Layer 2 connections, is reduced.
In traditional Layer 2 VPN technology that is based on LDP and BGP, the provider
network handled the provisioning activity for each Layer 2 circuit established between
two client routers.
[See GMPLS RSVP-TE VLAN LSP Signaling Overview and Example: Configuring GMPLS
RSVP-TE VLAN LSP Signaling.]
•
Extension of traceroute over MPLS tunnels—A new command as of Junos OS Release
14.2, traceroute mpls bgp enables you to perform end-to-end LSP traceroute by having
the transit routers provide information to the ingress router about the start and ending
of new tunnels for the following cases:
•
For hierarchical LSPs for the following use cases:
29
•
•
LBGP over LDP (traceroute explores all ECMP paths)
•
LBGP over RSVP (traceroute explores all ECMP paths)
•
LDP over RSVP (traceroute explores all ECMP paths)
•
RSVP over BYPASS
For stitched LSP case for LDP stitched to labeled BGP
The mechanism by which this is accomplished is explained in RFC 6424, which extends
RFC 4370. Use traceroute mpls bgp as a debugging tool to locate MPLS BGP forwarding
issues in a network. The traceroute mpls bgp command is supported on all platforms.
[See traceroute mpls bgp.]
Multicast
•
Dynamic bandwidth management using container LSPs (M Series, MX Series, and
T Series)—Starting with Junos OS Release 14.2, a new type of LSP, called a container
LSP, is introduced to enable load balancing across multiple point-to-point member
LSPs between the same ingress and egress routers. Each member LSP takes a different
path to the same destination and can be routed along a different IGP cost path.
Based on the configuration and aggregate traffic, a container LSP provides support
for dynamic bandwidth management by enabling the ingress router to dynamically
add and remove member LSPs through a process called LSP splitting and LSP merging
respectively. Member LSPs can also be re-optimized with different bandwidth values
in a make-before-break way.
[See Dynamic Bandwidth Management Using MP-LSP Overview and Example: Configuring
Dynamic Bandwidth Management Using MP-LSP.]
•
BGP link state distribution (M Series, MX Series, and T Series)—Junos OS Release
14.2 and later releases introduce a new mechanism to distribute topology information
across multiple areas and autonomous systems (ASs) by extending the BGP protocol
to carry link state information.
Earlier, this information was acquired using an IGP, which has scaling limitations when
it comes to distributing large a database. Using BGP provides a policy-controlled and
scalable means of distributing the multi-area and multi-AS topology information.
This information is used for computing paths for MPLS LSPs spanning multiple domains,
such as inter-area TE LSP, and enables external path computing entities, such as ALTO
and PCE, to acquire network topology.
[See Link State Distribution Using BGP Overview and Example: Configuring GMPLS
RSVP-TE VLAN LSP Signaling.]
•
30
MLD snooping (MX Series routers with MPCs)—Beginning with Junos OS Release
14.2, support for MLD snooping is available on MX Series routers with MPCs (MPC-1,
MPC-2, MPC-3, and MPC-4). MLD snooping restricts the forwarding of IPv6 multicast
traffic to only those interfaces in a bridge-domain/VPLS that have interested listeners.
The operational commands for mld-snooping, including defaults, behavior, logging,
and tracing, are the same as for IGMP snooping (which provides the same functionality
for IPv4 traffic).
•
Separate multicast snooping domains for different logical systems—Starting in Junos
OS Release 14.2, support for multicast, PIM, and IGMP snooping is available for named
logical systems on MX Series routers with Junos OS MPCs and DPC-based line cards.
What this means is that multicast traffic specific to one logical system does not have
to flood the entire bridge domain.
This enhancement extends all the available snooping functionality in the default logical
system (including separate routing tables, routing instances, policies, and interface
configurations) to all of the named logical systems on the router. Likewise, the output
of show commands is restricted to data from the named logical system only. The
master logical system, however, can view the states of any or all named logical systems
configured on the device.
For service providers, the main benefits of this change are the ability to provide
customers with distinct multicast domains for snooping and the ability to simplify
multicast snooping testing by collapsing multiple routers onto a single device via logical
systems. Multicast snooping per named logical systems also extends to MC-LAG in
logical systems that were introduced in Junos OS Release 14.1.
Multicast snooping in named logical systems does not support unified ISSU. We
recommend that, prior to performing unified ISSU, the provider remove all
IGMP-snooping specific configurations. Graceful Routing Engine switchover (GRES)
is not affected by this change. IGMP snooping support for P2MP in VPLS for logical
systems applies where such configurations are already valid.
•
Logical interfaces summary (MX Series)—Beginning with Junos OS Release 14.1R2,
a new show command, show interfaces summary, is available to display the status and
statistics on the logical interfaces configured on the device at the Flexible PIC
Concentrator (FPC) level.
[See show interfaces summary.]
•
Enhancements to SNMP statistics operational mode commands (M Series, MX
Series, and T Series)—Beginning with Junos OS Release 14.2, you can use the show
snmp stats-response-statistics command to view the statistics of SNMP statistics
responses sent from the Packet Forwarding Engine during the MIB II process (mib2d).
In addition, you can use the subagents option in the show snmp statistics command to
view the statistics of the protocol data units (PDUs) and the number of SNMP requests
and responses per subagent. The subagents option also helps you to view the SNMP
statistics received from each subagent per logical system.
•
SNMP support for enterprise-specific MVPN MIB (M Series and T Series)—Starting
with Junos OS Release 14.2, Junos OS SNMP supports the enterprise-specific MVPN
MIB. Junos OS SNMP support for MVPN is based on the enterprise-specific extension
of the IETF standard MIBs defined in Internet draft draft-ietf-l3vpn-mvpn-mib-03.txt,
MPLS/BGP Layer 3 VPN Multicast Management Information Base.
31
[See Juniper Networks Enterprise-Specific MIBs and Supported Devices, Juniper Networks
Enterprise-Specific MIBs, and SNMP MIBs and Traps Reference.]
•
Support for RFC 4133, Entity MIB (MX240, MX480, and MX960)—Starting with
Release 14.2, Junos OS supports tables and objects defined in RFC 4133, Entity MIB,
except:
•
entityLogicalGroup table
•
entityNotificationsGroup table
•
entPhysicalMfgDate and entPhysicalUris objects in entityPhysical2Group table
•
entLPMappingTable and entPhysicalContainsTable in entityMappingGroup table
[See Standard SNMP MIBs Supported by Junos OS.]
•
Support for RFC 4268, Entity State MIB (MX240, MX480, and MX960)—Starting
with Release 14.2, Junos OS supports all objects and tables defined in RFC 4268, Entity
State MIB.
•
Support for RFC 3635, Definitions of Managed Objects for the Ethernet-like Interface
Types (MX Series only)—Starting with Release 14.2, Junos OS supports all objects and
tables defined in RFC 3635, Definitions of Managed Objects for the Ethernet-like Interface
Types, except dot3StatsRateControlAbility and dot3StatsRateControlStatus in
dot3StatsEntry table.
[See Standard SNMP MIBs Supported by Junos OS.]
•
Enhancement to reduce the time taken for performing system commit (M Series,
MX Series, and T Series)—Beginning with Junos OS Release 14.2, you can configure
the delta-export statement at the [edit system commit] hierarchy level to reduce the
time taken to commit the configuration changes.
•
32
SNMP support for the timing feature—Starting in Junos OS Release 14.2, SNMP
supports the timing feature. Currently, SNMP support is limited to defect and event
notifications through SNMP traps. A new enterprise-specific MIB, Timing Feature
Defect/Event Notification MIB, has been added to monitor the operation of PTP clocks
within the network. The trap notifications are disabled by default. To enable trap
notifications for the timing feature, include the timing-event statement at the [edit
snmp trap-group trap-group object categories] hierarchy level to enable SNMP trap
notifications for timing events and defects.
Operation, Administration, and Maintenance (OAM)
•
Loopback tracking for IEEE 802.3ah OAM link-fault management (MX
Series)—Starting in Junos OS Release 14.2, MX Series routers support loopback tracking
for the Ethernet Operation, Administration, and Management (OAM) link-fault
management process (lfmd). When loopback tracking is enabled and the Ethernet
OAM lfmd process detects its own generated packets on an interface, it marks the
interface as down. When the loopback issue resolves, the interface is brought back up.
To enable loopback tracking for Ethernet OAM, include the loopback-tracking statement
at the [edit protocols oam ethernet link-fault-management interface] hierarchy level.
hierarchy level.
•
Virtual Route Reflector (VRR)—Starting in Junos OS Release 14.2, you can implement
route reflector capability using a general purpose virtual machine on a 64-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 and more flexible deployment using Intel servers rather than router hardware
•
Space savings through elimination of router hardware
•
New flexible offset firewall filter terms (MX Series routers with MPCs or MICs)—In
Junos OS releases prior to Release 14.2, you configured firewall filter terms configured
using the CLI only on pre-defined or fixed offsets within the IP packet, such as source
address, destination port, and so on. Starting in Junos OS Release 14.2, new flexible
offset firewall filter terms are available. These flexible offset filter terms allow a user
to begin the search for match conditions at Layer-2, Layer-3, Layer-4, or payload
locations within the IP packet and to vary the match parameters within those locations.
•
New firewall family bridge match criteria for IPv6 (MX Series routers with MPCs or
MICs)—For IPv4 traffic, the following header match criteria are supported in bridge
filters: IP source address, IP destination address, protocol type, and DiffServ code point
(DSCP). Starting in Junos OS Release 14.2, the same match criteria have been added
to the [firewall family bridge filter filter-name term rule-name from] hierarchy for the
matching of IPv6 fields in firewall bridge filters. In addition, the IPv6 next-header and
payload-protocol fields can be matched.
•
New walkup statement available (M Series, MX Series and T Series)—Starting in
Junos OS Release 14.2, a new walkup feature is available. The walkup feature allows
the user to change the default route filter prefix match behavior, so that the evaluation
will walk-up multiple route filters contained within a single policy term, in order to allow
matches on terms other than the default longest match. This can be applied globally
or locally to a single policy. This feature can be configured in the main routing instance
and in logical systems but not in routing instances.
33
Routing Protocols
•
Virtual route reflector using 64-bit routing processes (MX Series)—Starting with
Junos OS Release 14.2, many of the applications running on Junos OS can be shifted
to external and more robust, powerful computing resources, thereby preserving the
hardware resources on devices running Junos OS for switching and routing
functionalities. Among the protocols and modules that can be transferred to external
computing utilities, control plane protocols are suited for such an offloading. Such a
virtualized process can be run on more powerful blade servers, and the computed
entities can be downloaded to the router or the switch. With such an approach, the
scaling dimensions for each of the virtualized processes can be increased to a large
level.
Out of the various processes that run within rpd, route reflector is an operation that
requires a considerable amount of computing power (both with memory utilization
and computation overhead). Such a virtualized module, virtual route reflector, can be
run on external servers to achieve more scaling numbers. The virtualization of such
functional blocks enables the service to be run on external high-performance servers.
To enable this capability of a virtual route reflector, the entire Junos OS is virtualized
and launched as a VM (virtual machine). To achieve higher and effective scaling
numbers, rpd is configured as a 64-bit application, which benefits from a much better
address space. The 64-bit capacity of rpd requires the kernel to also be of 64-bit type.
The purpose of route reflection is loop prevention when the internal BGP (IBGP) routing
devices are not fully meshed. To accomplish this, RRs break one of the rules of normal
BGP operation: They readvertise routes learned from an internal BGP peer to other
internal BGP peers. A new Junos OS platform image called vrr64 is provided. You can
use the jinstall64-vrr package to install the 64-bit virtual route reflector on your device.
Raw disk image format is supported for the VRR image. The new Junos OS platform
image is converted to kernel-based virtual machine (KVM) or a Quick Emulator (QEMU)
disk image, which is launched as a VM on the QEMU hardware virtualizer.
•
BGP-static routes (MX Series)—Beginning with Junos OS Release 14.2, you can
configure and advertise BGP-static routes in a BGP network. You can advertise a
BGP-static route in a BGP network, even if it is not the active route for the prefix.
BGP-static routes do not flap unless they are deleted manually. You can define a policy
that determines which BGP-static routes need to be advertised and included in the
advertisements. Peer routers receive advertisements for these BGP-static routes
regardless of dynamic routing information learned by the advertising router.
To configure BGP-static routes, include the bgp-static route statement at the [edit
routing-options] hierarchy level.
[See BGP-Static Routes in a BGP Network.]
•
34
Remote LFA support for LDP in IS-IS (MX Series)—Beginning with Junos OS Release
14.2, you can configure a remote loop-free alternate (LFA) to extend the backup
provided by the LFA in an IS-IS network. This feature is useful especially for Layer 1
metro-rings where the remote LFA is not directly connected to the PLR. The existing
LDP implemented for the MPLS tunnel setup can be reused for the protection of IS-IS
networks and subsequent LDP destinations, thereby eliminating the need for RSVP-TE
backup tunnels for backup coverage.
To configure remote LFA over LDP tunnels, include the remote-backup-calculation
statement at the [edit protocols isis backup-spf-options] hierarchy level and the
auto-targeted-session statement at the [edit protocols ldp] hierarchy level.
[See Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks.]
Services Applications
•
IPsec invalid SPI notification (M Series, MX Series, and T Series)—Starting in Junos
OS Release 14.2, 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.
[See Configuring IKE Policies.]
•
IPv6 support for aggregated multiservices (AMS) interfaces (MX Series with
MS-MPCs)—Starting in Junos OS Release 14.2, you can use AMS interfaces for IPv6
traffic. To configure IPv6 support for an AMS interface, include the family inet6
statement at the [edit interfaces ams-interface-name unit 1] hierarchy level.
NOTE: When family inet and family inet6 are set for an AMS interface
sub-unit, the hash-keys set at the [edit services service-set-name
load-balancing-options] hierarchy level apply both to IPv4 and IPv6 flows.
•
ICMP, ping, and traceroute ALGs for MS-MICs and MS-MPCs (MX Series)—Starting
with Junos OS Release 14.2, Junos OS extension-provider packages that are preinstalled
and preconfigured on the MS-MIC and MS-MPC offer support for ping, traceroute, and
ICMP ALGs in a consistent manner that is identical to the support that the uKernel
service provides. Parity and uniformity of support is established for these ALGs between
MS-MICs/MS-MPCs and the uKernel service. Until Junos OS Release 14.1, ICMP ALGs,
ping ALGs, and traceroute ALGs were not entirely supported on MX Series routers with
MS-MICs and MS-MPCs in comparison with the uKernel service that enables Network
Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC. Support
was available for handling of ICMP error response packets that match any existing
flow in the opposite direction and NAT processing of ICMP packets with NAT processing
of ping packets.
•
Support for IP reassembly on GRE tunnel interfaces for (MX Series routers with
MPCs)—Starting with Junos OS Release 14.2, you can configure the generic routing
encapsulation (GRE) tunnel interfaces on MX Series routers with MPCs to support IP
packet reassembly. You can configure the GRE interfaces to reassemble the fragmented
packets at the endpoint of the tunnel before they can be further processed on the
network by including the reassemble-packets statement at the [edit interfaces
gr-fpc/pic/port unit logical-unit-number] hierarchy level. You can view the reassembly
35
statistics by using the show services inline ip-reassembly stastics <fpc fpc-slot | pfe
pfe-slot> command. Inline IP reassembly is supported on MX80, MX240, MX480,
MX960, MX2010, MX2020, and MX104 routers. The line modules compatible with the
corresponding MX Series routers that support the reassembly of GRE packets are MPC1,
MPC2, MPC3, MPC4, and MPC-16X10GE. Until Junos OS Release 14.1, reassembly of IP
fragments received at GRE tunnels is supported only on MX Series routers with
MS-DPCs.
•
Enhancements to the RFC 2544-based benchmarking tests (MX104)—RFC 2544
tests are performed by transmitting test packets from a device that functions as a
generator. These packets are sent to a device that functions as a reflector. The reflector
receives and reflects packets back to the generator. MX104 routers can be configured
as reflectors. Starting with Junos OS Release 14.2, MX104 routers support RFC
2544-based benchmarking tests for Ethernet transparent LAN (E-LAN) services
configured using bridge domains. The RFC 2544 tests are performed to measure and
demonstrate the service-level agreement (SLA) parameters before activation of the
service. The tests measure throughput, latency, frame loss rate, and back-to-back
frames. RFC 2544 performance measurement testing for Layer 2 E-LAN services on
MX104 routers supports user-to-network interface (UNI)-to-UNI unicast traffic only.
Software-Defined Networking (SDN)
•
Support for OpenFlow v1.3.1 (MX Series)—Starting with Junos OS Release 14.2, MX
Series routers support OpenFlow v1.3.1. In addition to the OpenFlow v1.0 functionality
that is already supported on MX Series routers, OpenFlow v1.3.1 allows the action
specified in one or more flow entries to direct packets to a base action called a group.
The purpose of the group action is to further process these packets and assign a more
specific forwarding action to them. You can view groups that were added, modified,
or deleted from the group table by the OpenFlow controller using the show openflow
groups command. You can view group statistics using the show openflow statistics
groups command.
[See Understanding How the OpenFlow Group Action Works.]
•
OVSDB support (MX Series)—Starting with Junos OS Release 14.2, the Junos OS
implementation of the Open vSwitch Database (OVSDB) management protocol
provides a means through which VMware NSX controllers and MX Series routers that
support OVSDB can communicate. In an NSX multi-hypervisor environment, NSX
controllers and MX Series routers can exchange control and statistical information,
thereby enabling virtual machine (VM) traffic from entities in a virtual network to be
forwarded to entities in a physical network and the reverse.
[See Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices and “Product Compatibility” on page 62.]
36
Subscriber Management and Services
NOTE: Although present in the code, the subscriber management features
are not supported in Junos OS Release 14.2. Documentation for subscriber
management features is included in the Junos OS Release 14.2 documentation
set.
•
Excluding diameter AVPs from JSRC messages (MX Series)—Starting in Junos OS
Release 14.2, you can configure the router to exclude the Diameter user-name (1) AVP
from authorization requests and provision requests sent to the SAE (remote SRC peer).
[See Excluding AVPs from Diameter Messages for JSRC.]
•
Support for PPPoE-Description VSA (MX Series)—Starting in Junos OS Release 14.2,
you can use Juniper Networks VSA 26-24 (PPPoE Description) when using RADIUS to
authenticate subscribers based on the client MAC address.
[See Juniper Networks VSAs Supported by the AAA Service Framework.]
•
DHCP relay agent for clients in different VRF than DHCP server (MX Series)—Starting
in Junos OS Release14.2, subscriber management provides enhanced security when
exchanging DHCP messages between a DHCP server and DHCP clients that reside in
different virtual routing instances (VRFs). The DHCP cross-VRF message 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 DHCP messages 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.
[See DHCP Message Exchange Between DHCP Clients and DHCP Server in Different VRFs
.]
•
ANCP agent adjustment of downstream data rate and overhead for SDSL, VDSL,
and VDSL2 subscriber lines (MX Series)—Starting in Junos OS Release 14.2, you can
configure the ANCP agent to provide two independent, adjusted values to CoS for
downstream subscriber traffic on frame mode DSL types (SDSL, VDSL, and VDSL2),
enabling CoS to more accurately adjust the effective shaping rate for the downstream
subscriber traffic. You can specify a percentage value that is applied to the actual,
unadjusted data rate received in ANCP Port Up messages. You can also specify a
number of bytes that is added to or subtracted from the frame overhead for the traffic.
[See Configuring the ANCP Agent to Report Traffic Rates to CoS.]
•
Concurrent support for PPPoE-over-ATM and IPoE-over-ATM subscriber interfaces
on a single ATM PVC (MX Series with MPCs and ATM MICs with SFP)—Starting in
Junos OS Release 14.2 for MX Series routers with ATM MICs with SFP installed, you
can configure subscriber interfaces for both PPP-over-Ethernet-over-ATM
(PPPoE-over-ATM) and IP-over-Ethernet-over-ATM (IPoE-over-ATM) concurrently
on a single ATM PVC. The concurrent PPPoE-over-ATM and IPoE-over-ATM
37
configuration supports all features specific to PPPoE-over-ATM interfaces and
IPoE-over ATM interfaces, with no changes.
To configure concurrent PPPoE-over-ATM and IPoE-over-ATM subscriber interfaces
on a single ATM PVC, you configure the ATM logical interface as an IPoE-over-ATM
interface by specifying the ether-over-atm-llc encapsulation type. You then use the
family pppoe stanza at the [edit interfaces at-fpc/pic/port unit logical-unit-number]
hierarchy level to configure PPPoE-over-ATM as a supported family. When the router
detects the family pppoe stanza and the IPoE-over-ATM encapsulation, it identifies
the configuration as concurrently supporting both PPPoE-over-ATM and IPoE-over-ATM
on the ATM PVC.
[See Configuring Concurrent PPPoE-over-ATM and IPoE-over-ATM Subscriber Interfaces
on an ATM PVC.]
•
Configuration support to change the maximum transmission unit size and maximum
receive unit size for PPP subscriber access—To prevent frequent fragmentation and
reassembly of Point-to-Point Protocol (PPP) packets, in Junos OS Release 14.2, you
can configure the PPP maximum transmission unit (MTU) size and the maximum
receive unit (MRU) size that is sent during link control protocol (LCP) negotiation for
the following PPP subscribers:
•
PPP over Ethernet (PPPoE) subscribers
•
PPP over Ethernet over ATM (PPPoE over ATM) subscribers
•
PPP over ATM (PPPoA) subscribers
•
Tunneled PPP LAC subscribers
•
Tunneled PPP LNS subscribers
To configure the MTU size for each of the PPP subscribers, include the mtu (size |
use-lower-layer) statement, and to configure the MRU size, include the mru size
statement at the following hierarchy levels:
•
For dynamic and static PPP LNS subscribers associated with a group profile—[edit
access group-profile group-profile-name ppp ppp-options]
•
For dynamic PPP subscribers—[edit dynamic-profiles profile-name interfaces pp0
unit “$junos-interface-unit” ppp-options]
•
For dynamic LNS subscribers—[edit dynamic-profiles profile-name interfaces
"$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options]
•
38
•
For static PPP subscribers—[edit interfaces pp0 unit unit-number ppp-options]
•
For static LNS subscribers—[edit interfaces si interface-id unit unit-number ppp-options]
Support for IP reassembly on an L2TP connection (MX Series routers with MPC3E
and MPC4E)—Starting in Junos OS Release 14.2, you now configure the service
interfaces on MX Series routers with MPC3E and MPC4E to support IP packet
reassembly on a Layer 2 Tunneling Protocol (L2TP) connection. The IP packet is
fragmented over an L2TP connection when the packet size exceeds the maximum
transmission unit (MTU) defined for the connection. Depending on the direction of the
traffic flow, the fragmentation can occur either at the L2TP access concentrator (LAC)
or at the L2TP network server (LNS) and reassembly occurs at the peer interface. (In
an L2TP connection, a LAC is a peer interface for the LNS and vice versa).
You can configure the service interfaces on the LAC or on the LNS to reassemble the
fragmented packets before they can be further processed on the network. On a router
running Junos OS, a service set is used to define the reassembly rules on the service
interface. The service set is then assigned to the L2TP service at the [edit services l2tp]
hierarchy level to configure IP reassembly for L2TP fragments.
You can view the reassembly statistics by using the show services inline ip-reassembly
stastics fpc fpc-slot | pfe pfe-slot> command.
[See IP Packet Fragment Reassembly for L2TP Overview.]
•
Global support for LAC forwarding of subscriber line information (MX
Series)—Starting in Junos OS Release 14.2, you can configure the LAC to forward
subscriber line information and optionally to include the Connection Speed Update
Enable AVP (98) for all destinations with the access-line-information statement at
the [edit services l2tp] hierarchy level. In earlier releases, you can configure this only
on a per-destination basis. Both the global and per-destination configurations are
disabled by default.
The global and per-destination settings interact in the following way:
•
Access line information—You can enable forwarding at the global or per-destination
level. When forwarding is enabled globally, you cannot disable the global setting for
a specific destination.
•
Connection speed updates—You can enable updates at the global or per-destination
level. You can disable the global setting for a specific destination by specifying
access-line-information for the destination and omitting connection-speed-update.
[See Subscriber Access Line Information Forwarding by the LAC Overview.]
•
Support for allowing commands in a Junos OS op script (M Series, MX Series, and
T Series)—Starting with Junos OS Release 14.2, you can specify a regular expression
that defines which commands to explicitly allow during execution of a Junos OS op
script. The commands that you specify are performed even if a user login class denies
that command. The permission to perform commands within a script applies to all
users.
[See Defining Commands to Allow in an Op Script.]
VPNs
•
VRF localization (MX Series with MPC)—Starting with Junos OS Release 14.2, VRF
localization provides a mechanism for localizing routes of VRF to specific line cards to
help maximize the number of routes that a router can handle. CE-facing interfaces
localize all the routes of instance type VRF to specific line cards. If CE-facing interfaces
are logical interfaces like AE or RLSQ or IRB, then the line card number has to be
configured to localize routes. Core-facing line cards store all the VRF routes. These
cards have to be configured as VPN core-facing only or VPN core-facing default. To
39
configure VRF localization, configure the localized-fib configuration statement at the
[edit routing-instances instance-name routing-options] hierarchy level and configure
vpn-localization at the [edit chassis fpc fpc-slot] hierarchy level. The show route
vpn-localization command displays the localization information of all the VRFs in the
system.
[See Example: Configuring VRF Localization on MX Series.]
•
Loop prevention in VPLS network due to MAC moves (MX Series)—Starting with
Junos OS Release 14.2, the base learning interface approach and the statistical approach
can be used to prevent a loop in a VPLS network by disabling the suspect
customer-facing interface that is connected to the loop. Some virtual MACs can
genuinely move between different interfaces and such MACs can be configured to
ignore the moves. The cooloff time and statistical approach wait time are used internally
to find out the looped interface. The interface recovery time can be configured to
auto-enable the interface that gets disabled due to a loop in the network. To configure
these parameters of VPLS MAC moves, include the vpls-mac-move statement at the
[edit protocols l2-learning] hierarchy level. The show vpls mac-move-action instance
instance-name command displays the learning interfaces that are disabled, in a VPLS
instance due to a MAC move. The clear vpls mac-move-action interface ifl-name
command enables an interface disabled due to a MAC move.
[See Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves.]
Related
Documentation
•
•
•
•
•
•
of Junos OS statements and commands from Junos OS Release 14.2R1 for the M Series,
MX Series, and T Series.
40
•
High Availability (HA) and Resiliency on page 41
•
•
MPLS on page 42
•
•
Network Address Translation (NAT) on page 43
•
•
•
Services Applications on page 45
•
Subscriber Management and Services on page 45
•
•
Enhanced show virtual-chassis heartbeat command (MX Series with MPCs)—Starting
in Junos OS Release 14.2, a new state, Detected, has been added to the show
virtual-chassis heartbeat command display output. When you configure a heartbeat
connection in an MX Series Virtual Chassis, the Detected state indicates that the master
Routing Engine in the specified member router has successfully exchanged a heartbeat
connection message with the other member router when an adjacency disruption or
split occurs in the Virtual Chassis. The Detected state persists until the heartbeat
connection is reset, or until the Virtual Chassis forms again and a master router (protocol
master) and backup router (protocol backup) are elected.
In previous releases, the show virtual-chassis heartbeat command displayed the Alive
state for both split and merged Virtual Chassis conditions when a heartbeat message
was successfully exchanged between the member routers. As a result, the only way
to detect whether a heartbeat connection was in use during an adjacency split or
disruption was to check for the Heartbt status in the show virtual-chassis status
command. The new Detected state in the show virtual-chassis heartbeat command
enables you to use a single command to determine whether or not the heartbeat
message was successfully exchanged during an adjacency split.
[See show virtual-chassis heartbeat.]
•
Distributed denial-of-service protection policer added for system log messages (MX
Series)—Starting in Junos OS Release 14.2, a new protocol-group policer is available
for system log messages. This aggregate policer controls UDP traffic on port 6333,
where the system log server runs on a Routing Engine. In a network where the local
Routing Engine is the system log server, you can use this policer to control the rate at
which system log messages reach the Routing Engine. You can configure values
appropriate for your network environment at the [edit system ddos-protection protocols
syslog aggregate] hierarchy level. The syslog policer is enabled by default, with a default
bandwidth of 2000 packets per second and a default burst of 10,000 packets.
•
Support for LLDP frames on management interfaces (MX Series)—Starting with
Junos OS Release 14.2, LLDP protocol can be enabled on management interfaces (fxp0
and me0) by including the interface interface-name statement or the interface all
statement at the [edit protocols lldp] and [edit routing-instances routing-instance-name
protocols lldp] hierarchy levels. The outputs of various LLDP show commands have
been enhanced to display the LLDP specific local and remote neighbor information on
these management ports, if LLDP is enabled on these ports.
41
MPLS
•
Enhanced show ldp database and show ldp overview commands—Starting in Junos
OS Release 14.2, the show ldp database command includes a new option and two new
output fields that provide enhanced information about LDP label accounting. The
command now includes a Labels received field in the Input label database section and
a Labels advertised field in the Output label database section. A new option, summary,
displays how many labels are received and sent for each LDP session. The show ldp
overview command includes a new field, Label allocation, that displays how many LDP
labels are allocated, how many are freed, how many have experienced failure, and the
number allocated by all protocols. These enhancements enable you to debug label
exhaustion events more easily.
[See show ldp database.]
•
Enhanced support for GRE interfaces for GMPLS (MX Series)—Starting in Junos OS
Release 12.3R7, on GRE interfaces for Generalized MPLS control channels, you can
enable the inner IP header’s ToS bits to be copied to the outer 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.]
•
Changes to MPLS protection options—In Junos OS releases prior to Release 14.2, you
can configure both fast reroute and node and link protection on the same LSP. In Junos
OS Release 14.2 and later releases, you can still configure both fast reroute and node
and link protection on the same LSP; however, when you attempt to commit a
configuration where both features are enabled, a syslog warning message is displayed
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>.
•
Enhanced transit LSP statistics collection—Starting in Junos OS Release 14.2, RSVP
no longer periodically polls for transit LSP statistics. This change does not affect the
show mpls 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 protocols mpls statistics] hierarchy
level. You cannot enable transit LSP statistics collection if MPLS statistics collection
is disabled with the no-transit-statistics statement at the [edit protocols mpls statistics]
hierarchy level.
This issue was being tracked by PR984000.
[See statistics.]
Multicast
•
Change to show pim join summary command—Starting in Junos OS Release 14.2, the
XML output of the show pim join summary command has changed. The new CLI output
introduces an extra XML hierarchy to separate the tags with the same name.
user@host> show pim join summary | display xml
42
[snip]
<join-family junos:style="summary">
<pim-instance>PIM.master< /pim-instance>
<address-family>INET< /address-family>
<join-summary-all>
<join-summary>
<multicast-route-type>(s,g)< /multicast-route-type>
<multicast-route-count>1000< /multicast-route-count>
</join-summary>
<join-summary>
<multicast-route-type>(*,g)< /multicast-route-type>
<multicast-route-count>2< /multicast-route-count>
</join-summary>
</join-summary-all>
</join-family>
[snip]</output>
</sample>
Network Address Translation (NAT)
•
Support for a new option to configure sequential allocation of ports for NAT (MX
Series)— Until Junos OS Release 14.1, you could include the port automatic statement
at the [edit services nat pool nat-pool- name] hierarchy level without having to use the
auto option with the port automatic statement. Although the default method of
assignment of ports was sequential (indicated by the auto option), the auto option
was not required to be specified. Starting with Junos OS Release 14.2, the sequential
option is introduced to enable you to configure sequential allocation of ports. The
sequential and random-allocation options available with the port automatic statement
at the [edit services nat pool nat-pool-name] hierarchy level are mutually exclusive.
You can include the sequential option for sequential allocation and the
random-allocation option for random delegation of ports. By default, sequential
allocation of ports takes place if you include only the port automatic statement at the
[edit services nat pool nat-pool-name] hierarchy level. The auto option is hidden and is
deprecated in Junos OS Release 14.2 and later, and is only maintained for backward
compatibility. It might be removed completely in a future software release.
If you upgrade a router running a Junos OS release earlier than Release 14.2 to Release
14.2 and if the router contains the port automatic statement defined without the auto
option included with the configuration, the router validates the auto option present in
the configuration for sequential allocation of ports.
•
New option for show firewall command—Starting in Junos OS Release 14.2, the show
firewall command supports a new option, filter regex regular-expression, that enables
you to display information about a subset of firewall filters. For regular-expression,
include a regular expression that matches the specific names of filters for which you
want to display information. Previously, the command only allowed you to display
information either about all filters or a specific filter. This enhancement enables devices
configured with a very large number of filters to display information about a subset of
filters more efficiently.
[See show firewall.]
43
•
Support for shared firewall filters across multiple routing instances (MX Series
routers with MPCs)—Starting in Junos OS Release 14.2, on MX Series routers with
Modular Port Concentrators (MPCs) only, you can specify to share one or more firewall
filters across multiple routing instances. Multiple firewall filters can be shared only
when network services for the device are configured with enhanced IP mode. By default,
firewall filters are not shared automatically across multiple routing instances. Include
the instance-shared statement at the [edit firewall family protocol-family-name filter
filter-name] hierarchy level. You can configure a combination of shared and nonshared
filters on the same routing device. This feature can be used with the following protocol
families: Bridge, IPv4, IPv6, Layer 2 CCC, MPLS, and VPLS.
[See Guidelines for Configuring Firewall Filters.]
Routing Protocols
•
Support for loss-of-continuity check per remote MEP (MX Series)—Beginning with
Junos OS Release 14.2, you can specify that Ethernet OAM continuity checks are
performed for an individual remote maintenance end point (MEP) by including the
detect-loc statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain md-name maintenance-association ma-name mep mep-id
remote-mep mep-id] hierarchy level. A loss-of-continuity (LOC) defect is declared if
no continuity check message is received from the remote MEP within a period equal
to 3.5 times the continuity check interval configured for the maintenance association.
If this occurs, the show oam ethernet connectivity-fault-management interfaces detail
command displays a value of yes for the Remote MEP not receiving CCM defect field.
The error also generates a syslog CFMD_CCM_DEFECT_RMEP message.
•
Support for BFD for IS-IS IPv6 interfaces—Starting in Junos OS Release 14.1R2,
bidirectional forwarding detection (BFD) is supported for IS-IS IPv6 interfaces. Include
the bidirectional-forwarding-detection statement at the [edit protocols isis interface
interface-name] hierarchy level. By default, multiple BFD sessions over a single adjacency
for IPv4 and IPv6 interfaces that belong to the same IS-IS instance are not automatically
created. To enable BFD on IPv4 and IPv6 interfaces configured on the same IS-IS
instance, you must also include the new bfd-per-address-family statement at the [edit
protocols isis interface interface-name] hierarchy level. When BFD is enabled for both
IPv4 and IPv6 interfaces in a single IS-IS instance, a BFD session is created for each
protocol family interface. If either the IPv4 or IPv6 session fails, the adjacency is torn
down.
[See Example: Configuring BFD for IS-IS.]
•
Introduction of the all keyword to prevent accidental execution of certain clear
commands—The all keyword is introduced in Junos OS Release 14.2 (as an optional
keyword). This makes users explicitly select the all keyword to clear all protocol or
session information. Thus, it prevents accidental clearing or resetting of protocols or
neighbor sessions, which might disrupt network operations.
The all keyword is introduced for the following clear commands:
44
•
clear arp
•
clear bgp neighbor
•
clear bfd adaptation
•
clear bfd session
•
clear igmp membership
•
clear isis adjacency
•
clear isis database
•
clear ldp neighbor
•
clear ldp session
•
clear mld membership
•
clear mpls lsp
•
clear msdp cache
•
clear multicast forwarding-cache
•
clear (ospf | ospf3) database
•
clear (ospf | ospf3) neighbor
•
clear pim join
•
clear pim join-distribution
•
clear pim register
•
clear rsvp sessions
•
Increase in the default rate of transmission of system logs to an external syslog
server (MX Series)—Starting with Junos OS Release 14.2 the maximum number of
system log messages per second to an external syslog server has been increased from
200,000 to 800,000 logs.
Subscriber Management and Services
NOTE: Although present in the code, the subscriber management features
are not supported in Junos OS Release 14.2R1. Documentation for subscriber
management features is included in the Junos OS Release 14.2 documentation
set.
•
Locally configured DNS addresses displayed in the result of the test aaa (dhcp | ppp)
command (MX Series)—Starting in Junos OS Release 14.2, if RADIUS does not return
any DNS addresses, then the output of the test aaa (dhcp | ppp) command includes
any locally configured DNS addresses.
[See Testing a Subscriber AAA Configuration.]
•
Support for applying access profiles to DHCP local server and DHCP relay
agent—Access profiles enable you to specify subscriber access authentication and
45
accounting parameters. After access profiles are created, you can attach them at the
[edit system services dhcp-local-server] hierarchy level on a DHCP local server for DHCP
or DHCPv6 subscribers and at the [edit forwarding-options dhcp-relay] hierarchy level
on a DHCP relay agent for DHCP or DHCPv6 subscribers, group of subscribers, or group
of interfaces.
If you configured a global access profile at the [edit access profile profile-name] hierarchy
level for all DHCP or DHCPv6 clients on a router that functions as a DHCP local server
or a DHCP relay agent, the access profile configured at the [edit system services
dhcp-local-server] or [edit system services dhcpv-local-server dhcpv6] hierarchy level
on a DHCP local server for DHCP or DHCPv6 subscribers and at the [edit
forwarding-options dhcp-relay] or [edit forwarding-options dhcp-relay dhcpv6] hierarchy
level on a DHCP relay agent for DHCP or DHCPv6 subscribers take precedence over
the global access profile.
Configuring an access profile for DHCP subscribers at the DHCP relay agent level or
the DHCP local server level provide you with the flexibility and effectiveness of enabling
DHCP authentication and accounting for specific subscribers instead of enabling them
at a global level. If no access profile is configured at the DHCP relay agent level or the
DHCP local server level, the global access profile becomes effective.
•
Support for processing Cisco VSAs in RADIUS messages for service
provisioning—Starting with Junos OS Release 14.2, Cisco VSAs are supported for
provisioning and management of services in RADIUS messages, in addition to the
supported Juniper Networks 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 the protocol, and the Cisco BroadHop application might be used as
the Policy Control and Charging Rules Function (PCRF) server for provisioning services
using RADIUS change of authorization (CoA) messages. Both the SBRC and the Cisco
BroadHop servers are considered to be connected with the broadband gateway in such
a 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 access profile profile-name service accounting] hierarchy
level.
You can configure the router to collect time statistics, or both volume and time statistics,
for the service accounting sessions being managed by AAA. 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
46
Known Behavior
statistics volume-time statement at the [edit access profile profile-name service
accounting] hierarchy level.
•
Specifying the UDP port for RADIUS dynamic-request servers—Starting in Junos OS
Release 14.2, you can define the UDP port number to configure the port on which the
router that functions as the RADIUS dynamic-request server must 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 [edit access radius-server server-address] hierarchy level.
•
Changed destination file format for transfer-on-commit feature (M Series, MX Series,
and T Series)—Starting with Junos OS Release 14.2, the format of the destination
filename for the transfer-on-commit feature is changed from
router-name_juniper.conf.n.gz_YYYYMMDD_HHMMSS to
router-name_YYYYMMDD_HHMMSS_juniper.conf.n.gz.
[See archive-sites and Using Junos OS to Configure a Router or Switch to Transfer Its
Configuration to an Archive Site.]
Related
Documentation
•
•
•
•
•
•
Known Behavior
This section contains the known behavior, system maximums, and limitations in hardware
and software in Junos OS Release 14.2R1 for the M Series, MX Series, and T Series.
•
•
•
The MPC5E, MPC5EQ, and MP6E cards do not support unified ISSU on an MX Series
Virtual Chassis.
•
In an MX Series Virtual Chassis configuration, a unified in-service software upgrade
(ISSU) from Junos OS Release 14.1 or 14.1R2 to Junos OS Release 14.2 fails with traffic
47
loss. As a workaround, download the latest build of Junos OS Release 14.1R3, which
contains a fix for this issue, and perform a unified ISSU to this build from Junos OS
Release 14.1R1 or 14.1R2. You can then successfully perform a unified ISSU from the
latest build of Junos OS Release 14.1R3 to Junos OS Release 14.2 in an MX Series Virtual
Chassis.
Related
Documentation
•
On MX Series routers running OpenFlow 1.3.1 software, the output for the show openflow
flows command displays IPv6-related fields. However, the Junos OS implementation
of OpenFlow 1.3.1 for MX Series routers does not currently support IPv6 specifications.
Therefore, the output for these fields typically display None.
•
On MX Series routers running OpenFlow 1.3.1 software, flow statistics show that the
packet flow is increasing even when the output port link is down. PR987753
•
On MX Series routers running OpenFlow 1.3.1 software, the ADPC might create a core
file. Configure enhanced IP network services mode to disable the ADPC. PR988256
•
•
•
•
•
•
Known Issues
for the M Series, MX Series, and T Series.
48
•
Forwarding and Sampling
•
General Routing
•
•
Layer 2 Features
•
Multiprotocol Label Switching (MPLS)
•
•
Routing Protocols
•
•
•
VPNs
Known Issues
Forwarding and Sampling
•
Remote vtep interface is not created despite sending traffic from inter segment, after
vtep router reboots or chassisd is restarted. It causes dropping packets. PR1016446
•
Adding "fast-lookup-filter" knob to a firewall filter using one or more terms with
"next-term" action could cause dfwc crash during commit (commit check phase).
Hence because of this bug, this disallows use of "fast-lookup-filter" feature on firewall
filters with terms using "next-term". This PR fixes the above bug exposed during firewall
compiler optimization of filters using next-terms and fast-lookup-filter. PR1029761
General Routing
•
In this scenario the CPCD (captive-portal-content-delivery) is configured for
HTTP-REDIRECT for Subscriber Management clients using MS-DPC. When services
sessions start to redirect the HTTP traffic, the memory-usage consistently increments
for MSPMAND on the multi-service PIC. The memory limit then might cause packets
loss. PR954079
•
When back to back GRES switchovers are done on multiple routers simultaneously,
one or more routers may core with kernel return duplicate NHID with rpd. PR987102
•
If a user configures a MX VC member with member ID 2, the VC's master Routing Engine
may eventually experience a kernel panic. PR989291
•
A new global knob is added at the top level CLI "set forwarding-options port-mirroring
[no-preserve-ingress-tag]". By default the system behavior would remain as it is today
where ingress mirrored copy would contain vlan content exactly as what came in wire
over ingress. However, if this knob is configured, if any vlan modification happens to
packet as part of its datapath processing, that would get retained in the ingress mirrored
copy, that is we will not restore vlan to what came in ingress on wire. PR1015149
•
Trace file size is already limited to 1 Mega bytes, but the actual issue is different. When
file reaches its maximum allowed size, an attempt is made to rotate trace file. But
trace files count is presently set to 0 (default), so rotate is not functional. As a result
all logs are appended to the same trace file even after crossing max limit. PR1021076
•
Enabling sampling on an ms- interface is not supported configuration. If
'forwarding-opions sampling sample-once' is subsequently deactivated the FPC may
reboot. PR1021946
•
In a rare case, rdd core is reported under /usr/sbin/rdd as soon as applying the group
and commit is performed. PR1029810
•
PCS statistics counter is now displayed for PTX 100GE interfaces in below command:
monitor interface <intf>. PR1030819
49
•
In L2 circuit, with async notification confiugred on a client facing interface goes down,
then on the remote PE the corresponding CE interface shows up in show interface terse
output while in log snmp reports interface down. PR1001547
•
ISIS Adjacency may flap after unified ISSU. This behavior is being further analyzed and
fixed in further releases. PR1015895
•
"set forwarding-options enhanced-hash-key symmetric" knob will not get applied on
MX104 PFE. PR1028931
•
When "clear bfd session" is issued immediately (before the Poll - Final sequence is
completed) post config check-in for interval change from higher to lower
minimum-interval value, BFD sessions don't revert to lower interval.PR1033231
Layer 2 Features
•
In a mixed VPLS instance where both ldp and bgp flavors are present, any cli change
in that instance will result in RPD crash. PR1025885
Multiprotocol Label Switching (MPLS)
•
For point-to-multipoint LSPs configured for VPLS, the "ping mpls" command reports
100 percent packet loss even though the VPLS connection is active. PR287990
•
The rate-limit value does not match between Routing Engine and Packet Forwarding
Engine. PR1023809
•
When a layer 2 frame entered the VPLS end point on the label switched interface (LSI)
interface with VLAN tagged, the frame is wrongly interpreted and treated as no VLAN
frame. So the VLAN tag will not be popped although the outbound interface has a pop
configuration. PR1027513
Routing Protocols
50
•
When you configure damping globally and use the import policy to prevent damping
for specific routes, and a peer sends a new route that has the local interface address
as the next hop, the route is added to the routing table with default damping
parameters, even though the import policy has a nondefault setting. As a result, damping
settings do not change appropriately when the route attributes change. PR51975
•
Continuous soft core-dump may be observed due to bgp-path-selection code. RPD
forks a child and the child asserts to produce a core-dump. The problem is with
route-ordering. And it is auto-corrected after collecting this soft-assert-coredump,
without any impact to traffic/service. PR815146
Known Issues
•
In rare cases, RPD may write a core file with signature "rt_notbest_sanity: Path selection
failure on ..." The core is 'soft', which means there should be no impact to traffic or
routing protocols. The fix will come in 15.2, as it is complex. PR946415
•
If auto-export feature is enabled together with rib-groups configuration option, the rpd
process might crash. PR1028522
•
When you specify a standard application at the [edit security idp idp-policy policy-name
rulebase-ips rule rule-name match application] hierarchy level, IDP does not detect
the attack on the nonstandard port (for example, junos:ftp on port 85). Whether it is
a custom or predefined application, the application name does not matter. IDP simply
looks at the protocol and port from the application definition. Only when traffic matches
the protocol and port does IDP try to match or detect against the associated attack.
PR477748
•
An MS-DPC PIC coredump may be generated if ICMP is used with EIM. PR1028142
•
User needs to wait until the page is completely loaded before navigating away from
the current page. PR567756
•
The J-Web interface allows the creation of duplicate term names in the Configure >
Security > Filters > IPV4 Firewall Filters page. But the duplicate entry is not shown in
the grid. There is no functionality impact on the J-Web interface. PR574525
•
Using the Internet Explorer 7 browser, while deleting a user from the Configure > System
Properties > User Management > Users page on the J-Web interface, the system is not
showing warning message, whereas in the Firefox browser error messages are shown.
PR595932
•
If you access the J-Web interface using the Microsoft Internet Web browser version 7,
on the BGP Configuration page (Configure > Routing > BGP), all flags might be shown
in the Configured Flags list (in the Edit Global Settings window, on the Trace Options
tab) even though the flags are not configured. As a workaround, use the Mozilla Firefox
Web browser. PR603669
•
On the J-Web interface, next hop column in Monitor > Routing > Route Information
displays only the interface address and the corresponding IP address is missing. The
title of the first column displays "static route address" instead of "Destination Address."
PR684552
51
VPNs
Related
Documentation
•
When you modify the frame-relay-tcc statement at the [edit interfaces interface-name
unit logical-unit-number] hierarchy level of a Layer 2 VPN, the connection for the
second logical interface might not come up. As a workaround, restart the chassis
process (chassisd) or reboot the router. PR32763
•
•
•
•
•
•
This section lists the errata and changes in Junos OS Release 14.2R1 documentation for
the M Series, MX Series, and T Series.
•
User Access and Authorization Feature Guide for Routing Devices on page 52
User Access and Authorization Feature Guide for Routing Devices
Related
Documentation
•
The “Configuring the SSH Protocol Version” topic incorrectly states that both version
1 and version 2 of the SSH protocol are enabled by default. The topic should state that
version 2 of the SSH protocol is enabled by default, and you must explicitly configure
version 1 if you want to enable it.
•
•
•
•
•
•
This section contains the procedure to upgrade Junos OS, and the upgrade and downgrade
policies for Junos OS for the M Series, MX Series, and T Series. Upgrading or downgrading
Junos OS can take several hours, depending on the size and configuration of the network.
52
•
Basic Procedure for Upgrading to Release 14.2 on page 53
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 55
•
Upgrading a Router with Redundant Routing Engines on page 55
•
Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS
Release 10.1 on page 56
•
Upgrading the Software for a Routing Matrix on page 57
•
Upgrading Using Unified ISSU on page 58
•
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and
NSR on page 59
•
Downgrading from Release 14.2 on page 60
•
Changes Planned for Future Releases on page 60
Basic Procedure for Upgrading to Release 14.2
In order to upgrade to Junos OS 10.0 or later, you must be running Junos OS 9.0S2, 9.1S1,
9.2R4, 9.3R3, 9.4R3, 9.5R1, or later minor versions, or you must specify the no-validate
option on the request system software install command.
When upgrading or downgrading Junos OS, always use the jinstall package. Use other
packages (such as the jbundle package) only when so instructed by a Juniper Networks
support representative. For information about the contents of the jinstall package and
details of the installation process, see the Installation and Upgrade Guide.
NOTE: With Junos OS Release 9.0 and later, the compact flash disk memory
requirement for Junos OS is 1 GB. For M7i and M10i routers with only 256 MB
memory, see the Customer Support Center JTAC Technical Bulletin
PSN-2007-10-001 at
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001
&actionBtn=Search
NOTE: Before upgrading, back up the file system and the currently active
Junos OS configuration so that you can recover to a known, stable
environment in case the upgrade is unsuccessful. Issue the following
command:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstalls
Junos OS. Configuration information from the previous software installation
is retained, but the contents of log files might be erased. Stored files on the
routing platform, such as configuration templates and shell scripts (the only
exceptions are the juniper.conf and ssh files) might be removed. To preserve
the stored files, copy them to another system before upgrading or
downgrading the routing platform. For more information, see the Junos OS
Administration Library for Routing Devices.
53
The download and installation process for Junos OS Release 14.2 is different from previous
Junos OS releases.
1.
Using a Web browser, navigate to the All Junos Platforms software download URL on
the Juniper Networks webpage:
http://www.juniper.net/support/downloads/
2. Select the name of the Junos platform for the software that you want to download.
3. Select the release number (the number of the software version that you want to
download) from the Release drop-down list to the right of the Download Software
page.
4. Select the Software tab.
5. In the Install Package section of the Software tab, select the software package for the
release.
6. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
7. Review and accept the End User License Agreement.
8. Download the software to a local host.
9. Copy the software to the routing platform or to your internal software distribution
site.
10. Install the new jinstall package on the routing platform.
NOTE: We recommend that you upgrade all software packages out of
band using the console because in-band connections are lost during the
upgrade process.
Customers in the United States and Canada, use the following command:
user@host> request system software add validate reboot
source/jinstall-14.2R11-domestic-signed.tgz
All other customers, use the following command:
user@host> request system software add validate reboot
source/jinstall-14.2R11-export-signed.tgz
Replace source with one of the following values:
•
/pathname—For a software package that is installed from a local directory on the
router.
•
54
For software packages that are downloaded and installed from a remote location:
•
ftp://hostname/pathname
•
http://hostname/pathname
•
scp://hostname/pathname (available only for Canada and U.S. version)
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 10 minutes.
Rebooting occurs only if the upgrade is successful.
NOTE: After you install a Junos OS Release 14.2 jinstall package, you cannot
issue the request system software rollback command to return to the previously
installed software. Instead you must issue the request system software add
validate command and specify the jinstall package that corresponds to the
previously installed software.
Upgrade and Downgrade Support Policy for Junos OS Releases
Support for upgrades and downgrades that span more than three Junos OS releases at
a time is not provided, except for releases that are designated as Extended End-of-Life
(EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can
upgrade directly from one EEOL release to the next EEOL release even though EEOL
releases generally occur in increments beyond three releases.
You can upgrade or downgrade to the EEOL release that occurs directly before or after
the currently installed EEOL release, or to two EEOL releases before or after. For example,
Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from Junos
OS Release 10.0 to Release 10.4 or even from Junos OS Release 10.0 to Release 11.4.
However, you cannot upgrade directly from a non-EEOL release that is more than three
releases ahead or behind. For example, you cannot directly upgrade from Junos OS
Release 10.3 (a non-EEOL release) to Junos OS Release 11.4 or directly downgrade from
Junos OS Release 11.4 to Junos OS Release 10.3.
To upgrade or downgrade from a non-EEOL release to a release more than three releases
before or after, first upgrade to the next EEOL release and then upgrade or downgrade
from that EEOL release to your target release.
For more information on EEOL releases and to review a list of EEOL releases, see
http://www.juniper.net/support/eol/junos.html
Upgrading a Router with Redundant Routing Engines
If the router has two Routing Engines, perform a Junos OS installation on each Routing
Engine separately to avoid disrupting network operation as follows:
1.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
and save the configuration change to both Routing Engines.
2. Install the new Junos OS release on the backup Routing Engine while keeping the
currently running software version on the master Routing Engine.
55
3. After making sure that the new software version is running correctly on the backup
Routing Engine, switch over to the backup Routing Engine to activate the new software.
4. Install the new software on the original master Routing Engine that is now active as
the backup Routing Engine.
For the detailed procedure, see the Installation and Upgrade Guide.
Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos
OS Release 10.1
In releases prior to Junos OS Release 10.1, the draft-rosen multicast VPN feature
implements the unicast lo0.x address configured within that instance as the source
address used to establish PIM neighbors and create the multicast tunnel. In this mode,
the multicast VPN loopback address is used for reverse path forwarding (RPF) route
resolution to create the reverse path tree (RPT), or multicast tunnel. The multicast VPN
loopback address is also used as the source address in outgoing PIM control messages.
In Junos OS Release 10.1 and later, you can use the router’s main instance loopback
(lo0.0) address (rather than the multicast VPN loopback address) to establish the PIM
state for the multicast VPN. We strongly recommend that you perform the following
procedure when upgrading to Junos OS Release 10.1 if your draft-rosen multicast VPN
network includes both Juniper Network routers and other vendors’ routers functioning
as provider edge (PE) routers. Doing so preserves multicast VPN connectivity throughout
the upgrade process.
Because Junos OS Release 10.1 supports using the router’s main instance loopback (lo0.0)
address, it is no longer necessary for the multicast VPN loopback address to match the
main instance loopback adddress lo0.0 to maintain interoperability.
NOTE: You might want to maintain a multicast VPN instance lo0.x address
to use for protocol peering (such as IBGP sessions), or as a stable router
identifier, or to support the PIM bootstrap server function within the VPN
instance.
Complete the following steps when upgrading routers in your draft-rosen multicast VPN
network to Junos OS Release 10.1 if you want to configure the routers’s main instance
loopback address for draft-rosen multicast 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 the M7i and M10i routers
in the network have been upgraded to Junos OS Release 10.1.
2. After you have upgraded all routers, configure each router’s main instance loopback
address as the source address for multicast interfaces. Include the default-vpn-source
interface-name loopback-interface-name] statement at the [edit protocols pim]
hierarchy level.
56
3. After you have configured the router’s main loopback address on each PE router,
delete the multicast VPN loopback address (lo0.x) from all routers.
We also recommend that you remove the multicast VPN loopback address from all
PE routers from other vendors. In Junos OS releases prior to 10.1, to ensure
interoperability with other vendors’ routers in a draft-rosen multicast VPN network,
you had to perform additional configuration. Remove that configuration from both
the Juniper Networks routers and the other vendors’ routers. This configuration should
be on Juniper Networks routers and on the other vendors’ routers where you configured
the lo0.mvpn address in each VRF instance as the same address as the main loopback
(lo0.0) address.
This configuration is not required when you upgrade to Junos OS Release 10.1 and use
the main loopback address as the source address for multicast interfaces.
NOTE: To maintain a loopback address for a specific instance, configure
a loopback address value that does not match the main instance address
(lo0.0).
For more information about configuring the draft-rosen Multicast VPN feature, see the
Multicast Protocols Feature Guide for Routing Devices.
Upgrading the Software for a Routing Matrix
A routing matrix can be either a TX Matrix router as the switch-card chassis (SCC) or a
TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you upgrade
software for a TX Matrix router or a TX Matrix Plus router, the new image is loaded onto
the TX Matrix or TX Matrix Plus router (specified in the Junos OS CLI by using the scc or
sfc option) and distributed to all line-card chassis (LCCs) in the routing matrix (specified
in the Junos OS CLI by using the lcc option). To avoid network disruption during the
upgrade, ensure the following conditions before beginning the upgrade process:
•
A minimum of free disk space and DRAM on each Routing Engine. The software upgrade
will fail on any Routing Engine without the required amount of free disk space and
DRAM. To determine the amount of disk space currently available on all Routing Engines
of the routing matrix, use the CLI show system storage command. To determine the
amount of DRAM currently available on all the Routing Engines in the routing matrix,
use the CLI show chassis routing-engine command.
•
The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC)
and all LCCs connected to the SCC or SFC are all re0 or are all re1.
•
The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC)
and all LCCs connected to the SCC or SFC are all re1 or are all re0.
•
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
57
the process include changing mastership, running the same version of software is
recommended.
•
For a routing matrix with a TX Matrix router, the same Routing Engine model is used
within a TX Matrix 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 TX Matrix Plus router, the SFC contains two model
RE-DUO-C2600-16G Routing Engines, and each LCC contains two model
RE-DUO-C1800-8G or RE-DUO-C1800-16G Routing Engines.
BEST PRACTICE: Make sure that all master Routing Engines are re0 and all
backup Routing Engines are re1 (or vice versa). For the purposes of this
document, the master Routing Engine is re0 and the backup Routing Engine
is re1.
To upgrade the software for a routing matrix, perform the following steps:
1.
(re0) and save the configuration change to both Routing Engines.
2. Install the new Junos OS release on the backup Routing Engine (re1) while keeping
the currently running software version on the master Routing Engine (re0).
3. Load the new Junos OS on the backup Routing Engine. After making sure that the new
software version is running correctly on the backup Routing Engine (re1), switch
mastership back to the original master Routing Engine (re0) to activate the new
software.
4. Install the new software on the new backup Routing Engine (re0).
For the detailed procedure, see the Routing Matrix with a TX Matrix Router Deployment Guide
or the Routing Matrix with a TX Matrix Plus Router Deployment Guide.
Upgrading Using Unified ISSU
in-service software upgrade (ISSU) functionality for M, MX, and T Series
routers. We do not recommend using unified ISSU to upgrade from an earlier
Junos OS release to Junos OS 14.2R1.
Unified in-service software upgrade (ISSU) enables you to upgrade between two different
Junos OS releases with no disruption on the control plane and with minimal disruption
of traffic. Unified in-service software upgrade is only supported by dual Routing Engine
platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active
58
routing (NSR) must be enabled. For additional information about using unified in-service
software upgrade, see the High Availability Feature Guide for Routing Devices.
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM
and NSR
Junos OS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the
following PIM features are not currently supported with NSR. The commit operation fails
if the configuration includes both NSR and one or more of these features:
•
Anycast RP
•
Draft-Rosen multicast VPNs (MVPNs)
•
Local RP
•
Next-generation MVPNs with PIM provider tunnels
•
PIM join load balancing
Junos OS Release 9.3 introduced a new configuration statement that disables NSR for
PIM only, so that you can activate incompatible PIM features and continue to use NSR
for the other protocols on the router: the nonstop-routing disable statement at the [edit
protocols pim] hierarchy level. (Note that this statement disables NSR for all PIM features,
not only incompatible features.)
If neither NSR nor PIM is enabled on the router to be upgraded or if one of the unsupported
PIM features is enabled but NSR is not enabled, no additional steps are necessary and
you can use the standard upgrade procedure described in other sections of these
instructions. If NSR is enabled and no NSR-incompatible PIM features are enabled, use
the standard reboot or ISSU procedures described in the other sections of these
instructions.
Because the nonstop-routing disable statement was not available in Junos OS Release
9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to
be upgraded from Junos OS Release 9.2 or earlier to a later release, you must disable
PIM before the upgrade and reenable it after the router is running the upgraded Junos
OS and you have entered the nonstop-routing disable statement. If your router is running
Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR
or PIM–simply use the standard reboot or ISSU procedures described in the other sections
of these instructions.
To disable and reenable PIM:
1.
On the router running Junos OS Release 9.2 or earlier, enter configuration mode and
disable PIM:
[edit]
user@host# deactivate protocols pim
user@host# commit
2. Upgrade to Junos OS Release 9.3 or later software using the instructions appropriate
for the router type. You can either use the standard procedure with reboot or use ISSU.
59
3. After the router reboots and is running the upgraded Junos OS, enter configuration
mode, disable PIM NSR with the nonstop-routing disable statement, and then reenable
PIM:
[edit]
user@host# set protocols pim nonstop-routing disable
user@host# activate protocols pim
user@host# commit
Downgrading from Release 14.2
To downgrade from Release 14.2 to another supported release, follow the procedure for
upgrading, but replace the 14.2 jinstall package with one that corresponds to the
appropriate release.
NOTE: You cannot downgrade more than three releases. For example, if your
routing platform is running Junos OS Release 11.4, you can downgrade the
software to Release 10.4 directly, but not to Release 10.3 or earlier; as a
workaround, you can first downgrade to Release 10.4 and then downgrade
to Release 10.3.
For more information, see the Installation and Upgrade Guide.
Changes Planned for Future Releases
•
Introduction of the all keyword to prevent accidental execution of certain clear
commands—The all keyword is introduced in Junos OS Release 14.2 (as an optional
keyword) and is planned to be introduced in Junos OS Release 15.2 (as a mandatory
keyword) for certain clear commands that are used for clearing protocol and neighbor
sessions. This makes users explicitly select the all keyword to clear all protocol or
session information. Thus, it prevents accidental clearing or resetting of protocols or
neighbor sessions, which might disrupt network operations.
The all keyword is planned to be introduced for the following clear commands:
60
•
clear arp
•
clear bgp neighbor
•
clear bfd adaptation
•
clear bfd session
•
clear igmp membership
•
clear isis adjacency
•
clear isis database
•
clear ldp neighbor
•
clear ldp session
•
clear mld membership
•
clear mpls lsp
•
clear msdp cache
•
clear multicast forwarding-cache
•
clear (ospf | ospf3) database
•
clear (ospf | ospf3) neighbor
•
clear pim join
•
clear pim join-distribution
•
clear pim register
•
clear rsvp sessions
In Junos OS Release 14.2 and 15.1—the all keyword will be optional. Therefore, when
you type any of these clear commands followed by the ? in the CLI, the all keyword
would be listed as an option after the <[Enter]> keyword. You can execute the clear
command directly or with the all keyword to clear all information. For example, when
you type clear mpls lsp ?, you’ll see:
user@host> clear mpls lsp ?
Possible completions:
<[Enter]>
Execute this command
all
Reset 'all' the nontransit or egress LSPs
originating on this router
<<<<<<<<<<<<
autobandwidth
Clear LSP autobandwidth counters
logical-system
Name of logical system, or 'all'
name
Regular expression for LSP names to match
optimize
Perform nonpreemptive optimization computation now
...
Both clear mpls lsp or clear mpls lsp all will function identically in these releases.
In Junos OS Release 15.2 and later—the all keyword would be mandatory. Therefore,
when you type a clear command followed by the ? in the CLI, the <[Enter]> option to
execute the command directly (without specifying any options) would not be available.
For example, when you type clear mpls lsp ?, you would see all listed as an option but
not <[Enter]> to execute the command directly. Therefore, you would have to type
clear mpls lsp all and then press <[Enter]> if you want to clear information about all
the non transit or egress LSPs originating on the router.
user@host> clear mpls lsp ?
Possible completions:
all
Reset 'all' the nontransit or egress LSPs
originating on this router
<<<<<<<<<<<<
autobandwidth
Clear LSP autobandwidth counters
logical-system
Name of logical system, or 'all'
name
Regular expression for LSP names to match
optimize
Perform nonpreemptive optimization computation now
...
Related
Documentation
•
61
•
•
•
•
•
•
Software Compatibility on page 62
•
Software Compatibility
The Juniper Networks implementation of the Open vSwitch Database (OVSDB)
management protocol on the MX Series routers is supported with VMware NSX version
4.0.3.
special compatibility guidelines with the release, see the Hardware Guide and the Interface
Module Reference for the product.
To determine the features supported on M Series, MX Series, and T Series devices in this
release, use the Juniper Networks Feature Explorer, a Web-based application that helps
you to explore and compare Junos OS feature information to find the right software
release and hardware platform for your network. Find Feature Explorer at:
Related
Documentation
62
•
•
•
•
•
•
Junos OS Release Notes for PTX Series Packet Transport Routers
Junos OS Release Notes for PTX Series Packet Transport Routers
These release notes accompany Junos OS Release 14.2R1 for the PTX Series. They describe
new and changed features, limitations, and known and resolved problems in the hardware
and software.
webpage, located at http://www.juniper.net/techpubs/software/junos/.
in-service software upgrade (ISSU) functionality for PTX Series routers. We
do not recommend using unified ISSU to upgrade from an earlier Junos OS
release to Junos OS 14.2R1.
•
•
•
•
•
•
•
OS Release 14.2R1 for the PTX Series.
•
Hardware on page 64
•
•
•
Management on page 67
•
•
Network Management and Monitoring on page 67
•
•
•
63
Hardware
•
Support for 4-port 100 Gigabit Ethernet OTN PIC (PTX5000)—Starting with Junos
OS Release 14.2, a 4-port 100 Gigabit Ethernet OTN PIC—P2-100GE-OTN—is supported
on the FPC2-PTX-P1A FPC in PTX5000 routers.
[See Understanding the P2-100GE-OTN PIC.]
•
New AC PSM and PDU (PTX5000)—Starting with Junos OS Release 14.2, new AC
power supply modules (PSMs) and power distribution units (PDUs) are added to
provide power to the FPC2-PTX-P1A FPC and other components in a PTX5000 router.
You can install two redundant AC PDUs, and each AC PDU supports up to eight PSMs.
All PSMs are considered to be a part of single zone to provide power to a common
power bus. Run the show chassis hardware operational mode command to view the
AC PSM and PDU details.
[See show chassis hardware.]
•
Support for P2-10G-40G-QSFPP PIC on the FPC2-PTX-P1A FPC (PTX5000)—Starting
with Junos OS Release 14.2, the PTX5000 supports the P2-10G-40G-QSFPP PIC on
the FPC2-PTX-P1A FPC. You can configure the P2-10G-40G-QSFPP PIC to operate in
10-Gigabit Ethernet mode or in 40-Gigabit Ethernet mode.
[See P2-10G-40G-QSFPP PIC Overview.]
•
SFPP-10G-DT-ZRC2 (PTX Series)—The SFPP-10G-DT-ZRC2 tunable transceiver
provides a duplex 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 Juniper Networks specifications.
The SFPP-10G-DT-ZRC2 transceiver supports WAN-PHY and LAN-PHY modes. On
PTX Series routers the SFPP-10G-DT-ZRC2 transceiver also supports OTN rates of
10.70923 Gbps (OTU2) and 11.0957 Gbps (OTU2E). To configure the wavelength on
the transceiver, use the wavelength statement at the [edit interfaces interface-name
optics-options] hierarchy level.
The following interface modules support the SFPP-10G-DT-ZRC2 transceiver:
PTX Series PICs:
•
10-Gigabit Ethernet LAN/WAN OTN PIC with SFP+ (model number:
P1-PTX-24-10G-W-SFPP)—Supported in Junos OS Release 13.2R5, 13.3R3, 14.1R2,
14.2, and later
•
10-Gigabit Ethernet PIC with SFP+ (model number:
P1-PTX-24-10GE-SFPP)—Supported in Junos OS Release 13.2R5, 13.3R3, 14.1R2, 14.2,
and later
For more information about interface modules, see the “Cables and Connectors” section
in the Interface Module Reference for your router.
[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications, PTX Series Interface
Module Reference, and wavelength]
64
•
Per-port pseudowire class-of-service classification (PTX Series)—Starting with
Junos OS Release 14.2, port-based pseudowire class-of-service (CoS) classification
is supported on the PTX Series router.
[See Pseudowire Subscriber Logical Interfaces Overview.]
•
100-Gigabit Ethernet DWDM OTN PIC (PTX Series)—Starting in Junos OS Release
14.2, the 100-Gigabit dense wavelength division multiplexing (DWDM) optical transport
network (OTN) PIC enhances the transport performance monitoring feature by adding
new functionality. Transport performance monitoring includes the ability to configure
threshold crossing alerts (TCAs) by using the tca configuration statement under the
[edit interfaces interface-name otn-options] or [edit interfaces interface-name
optics-options] hierarchy level. Configuring the TCA values enable you to receive early
warnings, which makes it possible to proactively manage the link. In addition, the
following new commands have been added:
•
show interface transport pm
•
clear interface transport pm
[See tca.]
•
OTN support (PTX Series)—Starting with Junos OS Release 14.2, OTN features are
supported on the 24-port 10-Gigabit Ethernet OTN PIC P1-PTX-24-10G-W-SFPP. This
PIC is supported on the FPCs FPC-PTX-P1-A and FPC2-PTX-P1A in PTX5000 routers
and the FPCs FPC-SFF-PTX-P1-A and FPC-SFF-PTX-T in PTX3000 routers. The
following OTN framing modes are supported:
•
10-Gigabit Ethernet LAN PHY over OTU2e or OTU1e
•
10-Gigabit Ethernet WAN PHY over OTU2
The following forward error correction (FEC) types are supported:
•
GFEC (G.709)
•
EFEC (G.975.1 I.4)
•
UFEC (G.975.1 I.7)
•
None (no-FEC)
The performance and state of packet transport for OTN and optics modules are
monitored by using the transport-monitoring statement at the [edit interfaces] hierarchy
level.
[See Understanding the P1-PTX-24-10G-W-SFPP PIC and transport-monitoring.]
•
Support for REST interfaces (PTX Series)— Starting with Junos OS Release 14.2, PTX
Series routers support REST interfaces for secure connection to Junos OS devices and
execution of remote procedure calls, a REST API Explorer GUI enabling you to
65
conveniently experiment with any of the REST APIs, and a variety of formatting and
display options, including JSON support.
[See REST API Guide.]
•
Synchronous Ethernet clock synchronization (PTX Series)—Beginning with Junos
OS Release 14.2, Synchronous Ethernet clock synchronization is supported on the PTX
Series router. This feature enables the selection of the best timing source based upon
the Synchronization Status Message (SSM) TLV carried in the Ethernet Synchronization
Message Channel (ESMC), specified in ITU-T G.8264. This selection process is used
when primary and secondary clock sources are not already configured by the user.
[See Configuring an External Clock Synchronization Interface for PTX Series Packet
Transport Routers.]
•
Support for mixed-rate aggregated Ethernet bundles (PTX Series)—Beginning with
Junos OS Release 14.2, bundling of mixed-rate links is supported on the same
aggregated Ethernet interface on the PTX Series router. This feature supports
aggregated Ethernet bundles composed of links with differing line speeds (10G, 40G,
and 100G) on the same aggregated Ethernet interface, enabling egress unicast traffic
load balancing based upon the egress link rate.
NOTE: Mixed-rate aggregated Ethernet bundling is not applicable to
multicast traffic.
[See Configuring Aggregated Ethernet Interfaces on PTX Series Packet Transport Routers.]
66
Management
•
YANG module that defines the Junos OS configuration hierarchy (PTX
Series)—Starting with Junos OS Release 14.2, Juniper Networks provides a YANG
module that defines the Junos OS configuration hierarchy. You can download the YANG
module that defines the complete Junos OS configuration hierarchy for all devices
running that Junos OS release from the Juniper Networks website at
http://www.juniper.net/. You can also generate a YANG module that defines the
device-specific configuration hierarchy by using the show system schema module
configuration format yang operational mode command on the local device. The Juniper
Networks YANG module, configuration, is bound to the namespace URI
http://yang.juniper.net/yang/1.1/jc and uses the prefix jc.
Multicast
•
Multicast make-before-break feature (PTX Series)—Beginning with Junos OS Release
14.2, multicast make-before-break (MBB) transitioning between Multicast Beam Table
(MBT) trees is supported on PTX Series routers. This feature improves multicast
performance by making the new tree before breaking the existing tree, minimizing the
amount of multicast traffic dropped during the transition.
[See Multicast Overview.]
•
Enhancements to SNMP statistics operational mode commands (PTX
Series)—Beginning with Junos OS Release 14.2, you can use the show snmp
stats-response-statistics command to view the statistics of SNMP statistics responses
sent from the Packet Forwarding Engine during the MIB II process (mib2d). In addition,
you can use the subagents option in the show snmp statistics command to view the
statistics of the protocol data units (PDUs) and the number of SNMP requests and
responses per subagent. The subagents option also helps you to view the SNMP
statistics received from each subagent per logical system.
•
Enhancement to reduce the time taken for performing system commit (PTX
Series)—Beginning with Junos OS Release 14.2, you can configure the delta-export
statement at the [edit system commit] hierarchy level to reduce the time taken to
commit the configuration changes.
•
Input filter-based forwarding (PTX Series)—Beginning with Junos OS Release 14.2,
filter-based forwarding on ingress traffic is supported on the PTX Series router. This
feature enables the user to configure a filter that classifies packet flows based upon
packet fields and redirect the packets through different user-configured forwarding
tables. Input filter-based forwarding is supported for IPv4 and IPv6 traffic only.
67
[See Filter-Based Forwarding Overview.]
•
New walkup statement available (PTX Series)—Starting in Junos OS Release 14.2, a
new walkup feature is available. The walkup feature allows the user to change the
default route filter prefix match behavior, so that the evaluation will walk-up multiple
route filters contained within a single policy term, in order to allow matches on terms
other than the default longest match. This can be applied globally or locally to a single
policy. This feature can be configured in the main routing instance and in logical systems
but not in routing instances.
Routing Protocols
•
Remote LFA support for LDP in IS-IS (PTXSeries)—Beginning with Junos OS Release
14.2, you can configure a remote loop-free alternate (LFA) to extend the backup
provided by the LFA in an IS-IS network. This feature is useful especially for Layer 1
metro-rings where the remote LFA is not directly connected to the PLR. The existing
LDP implemented for the MPLS tunnel setup can be reused for the protection of IS-IS
networks and subsequent LDP destinations thereby eliminating the need for RSVP-TE
backup tunnels for backup coverage.
To configure remote LFA over LDP tunnels, include the remote-backup-calculation
statement at the [edit protocols isis backup-spf-options] hierarchy level and the
auto-targeted-session statement at the [edit protocols ldp] hierarchy level.
[See Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks.]
•
Support for allowing commands in a Junos OS op script (PTX Series)–-Starting with
Junos OS Release 14.2, you can specify a regular expression that defines which
commands to explicitly allow during execution of a Junos OS op script. The commands
that you specify are performed even if a user login class denies that command. The
permission to perform commands within a script applies to all users.
[See Defining Commands to Allow in an Op Script.]
Related
Documentation
68
•
•
•
•
•
•
of Junos OS statements and commands from Junos OS Release 14.2R1 for the PTX Series.
•
•
•
•
Change to interpolated WRED drop probability (PTX Series)—In Junos OS Releases
13.2R4, 13.3R2, and 14.1 and later, 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, interpolated WRED 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.
Routing Protocols
•
Modification to the default BGP extended community value (PTX Series)—Starting
in Release 14.1, Junos OS has modified the default BGP extended community value
used for MVPN IPv4 VRF route import (RT-import) to the IANA-standardized value.
Thus, the default behavior has changed such that the behavior of the
mvpn-iana-rt-import statement has become the default. The mvpn-iana-rt-import
statement is deprecated and should be removed from configurations.
•
Configuring regular expressions (PTX Series)—In all supported Junos OS releases,
regular expressions can no longer be configured if they require more than 64 MB 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
was made 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 places within the CLI. Exploitation of this vulnerability
can cause the Routing Engine to crash, leading to a partial denial of service. Repeated
exploitation can result in an extended partial outage of services provided by the routing
protocol process (rpd).
Related
Documentation
•
•
•
•
•
69
•
Known Behavior
There are no issues with the known behaviors, system maximums, and limitations in
hardware and software in Junos OS Release 14.2R1 for the PTX Series.
Related
Documentation
•
•
•
•
•
•
Known Issues
for the PTX Series.
•
General Routing
•
General Routing
•
CCG locks to cc-8k even when configured signal type is cc-8k-400, without
off-frequency. PR895450
•
When changing the speed from 10G to 1G multiple times, the ping will not work due to
the serdes not being in the right state. A restart of the pic could fix this issue. PR988663
•
This issue would happens in the following conditions. 1. Transit chained nh knob is
enabled for rsvp/ldp or on PTX platform where chained nh knob is enabled by default.
2. Load-balance is configured. PR994552
Related
Documentation
70
•
USB install fails. PR931231
•
•
•
•
•
•
There are no outstanding issues with the published documentation for Junos OS Release
14.2R1 for the PTX Series.
Related
Documentation
•
•
•
•
•
•
This section contains the procedure to upgrade Junos OS, and the upgrade and downgrade
policies for Junos OS for the PTX Series. Upgrading or downgrading Junos OS can take
several hours, depending on the size and configuration of the network.
•
Upgrading Using Unified ISSU on page 71
•
Upgrading a Router with Redundant Routing Engines on page 71
•
Basic Procedure for Upgrading to Release 14.2 on page 72
Upgrading Using Unified ISSU
in-service software upgrade (ISSU) functionality for PTX Series routers. We
do not recommend using unified ISSU to upgrade from an earlier Junos OS
release to Junos OS 14.2R1.
Unified in-service software upgrade (ISSU) enables you to upgrade between two different
Junos OS releases with no disruption on the control plane and with minimal disruption
of traffic. Unified in-service software upgrade is only supported by dual Routing Engine
platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active
routing (NSR) must be enabled. For additional information about using unified in-service
software upgrade, see the High Availability Feature Guide for Routing Devices.
Upgrading a Router with Redundant Routing Engines
If the router has two Routing Engines, perform a Junos OS installation on each Routing
Engine separately to avoid disrupting network operation as follows:
71
1.
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 the master Routing Engine.
3. After making sure that the new software version is running correctly on the backup
Routing Engine, switch over to the backup Routing Engine to activate the new software.
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 14.2
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: Back up the file system and the currently active Junos OS configuration
before upgrading Junos OS. This allows you to recover to a known, stable
environment if the upgrade is unsuccessful. Issue the following command:
user@host> request system snapshot
NOTE: The installation process rebuilds the file system and completely
reinstalls Junos OS. Configuration information from the previous software
installation is retained, but the contents of log files might be erased. Stored
files on the router, such as configuration templates and shell scripts (the only
exceptions are the juniper.conf and ssh files), might be removed. To preserve
the stored files, copy them to another system before upgrading or
downgrading the routing platform. For more information, see the Junos OS
Administration Library for Routing Devices.
72
NOTE: We recommend that you upgrade all software packages out of band
using the console because in-band connections are lost during the upgrade
process.
The download and installation process for Junos OS Release 14.2 is different from previous
Junos OS releases.
1.
Using a Web browser, navigate to the All Junos Platforms software download URL
on the Juniper Networks webpage:
http://www.juniper.net/support/downloads/
2. Select the name of the Junos OS platform for the software that you want to download.
3. Select the release number (the number of the software version that you want to
download) from the Release drop-down list to the right of the Download Software
page.
4. Select the Software tab.
5. In the Install Package section of the Software tab, select the software package for
the release.
6. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
7. Review and accept the End User License Agreement.
8. Download the software to a local host.
9. Copy the software to the routing platform or to your internal software distribution
site.
10. Install the new jinstall package on the router.
NOTE: After you install a Junos OS Release 14.2 jinstall package, you
cannot issue the request system software rollback command to return to
the previously installed software. Instead you must issue the request
system software add validate command and specify the jinstall package
that corresponds to the previously installed software.
a different release. Adding the reboot command reboots the router after the upgrade
is validated and installed. When the reboot is complete, the router displays the login
prompt. The loading process can take 5 to 10 minutes. 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 reboot source/jinstall-14.2
R11-domestic-signed.tgz
73
All other customers, use the following command:
user@host> request system software add validate reboot source/jinstall-14.2
R11-export-signed.tgz
Replace the source with one of the following values:
•
/pathname—For a software package that is installed from a local directory on the
router.
•
For software packages that are downloaded and installed from a remote location:
•
ftp://hostname/pathname
•
http://hostname/pathname
•
scp://hostname/pathname (available only for Canada and U.S. version)
a different release.
Adding the reboot command reboots the router after the upgrade is validated and
installed. When the reboot is complete, the router displays the login prompt. The
loading process can take 5 to 10 minutes.
Rebooting occurs only if the upgrade is successful.
NOTE: After you install a Junos OS Release 14.2 jinstall package, you cannot
issue the request system software rollback command to return to the previously
installed software. Instead you must issue the request system software add
validate command and specify the jinstall package that corresponds to the
previously installed software.
Related
Documentation
•
•
•
•
•
•
•
74
special compatibility guidelines with the release, see the Hardware Guide and the Interface
Module Reference for the product.
To determine the features supported on PTX Series devices in this release, use the Juniper
Networks Feature Explorer, a Web-based application that helps you to explore and
compare Junos OS feature information to find the right software release and hardware
platform for your network. Find Feature Explorer at:
Related
Documentation
•
•
•
•
•
•
75
Third-Party Components
This product includes third-party components. To obtain a complete list of third-party
components, see Overview for Routing Devices.
For a list of open source attributes for this Junos OS release, see Open Source: Source
Files and Attributions.
Finding More Information
For the latest, most complete information about known and resolved issues with Junos
OS, see the Juniper Networks Problem Report Search application at:
http://prsearch.juniper.net .
Juniper Networks Feature Explorer is a Web-based application that helps you to explore
and compare Junos OS feature information to find the correct software release and
hardware platform for your network. Find Feature Explorer at:
http://pathfinder.juniper.net/feature-explorer/.
Juniper Networks Content Explorer is a Web-based application that helps you explore
Juniper Networks technical documentation by product, task, and software release, and
download documentation in PDF format. Find Content Explorer at:
http://www.juniper.net/techpubs/content-applications/content-explorer/.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can provide feedback by using either of the following
methods:
•
Online feedback rating system—On any page at the Juniper Networks Technical
Documentation site at http://www.juniper.net/techpubs/index.html, simply click the
stars to rate the content, and use the pop-up form to provide us with information about
your experience. Alternately, you can use the online feedback form at
https://www.juniper.net/cgi-bin/docbugreport/.
•
E-mail—Send your comments to [email protected]. Include the document
or topic name, URL or page number, and software version (if applicable).
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need postsales technical support, you can access
our tools and resources online or open a case with JTAC.
•
76
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf .
Requesting Technical Support
•
Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/.
•
JTAC Hours of Operation —The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
•
Find CSC offerings: http://www.juniper.net/customers/support/
•
Search for known bugs: http://www2.juniper.net/kb/
•
Find product documentation: http://www.juniper.net/techpubs/
•
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
•
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications:
http://kb.juniper.net/InfoCenter/
•
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
•
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool located at https://tools.juniper.net/SerialNumberEntitlementSearch/.
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
•
Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
•
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit us at
http://www.juniper.net/support/requesting-support.html .
If you are reporting a hardware or software problem, issue the following command from
the CLI before contacting support:
user@host> request support information | save filename
To provide a core file to Juniper Networks for analysis, compress the file with the gzip
utility, rename the file to include your company name, and copy it to
ftp.juniper.net/pub/incoming. Then send the filename, along with software version
information (the output of the show version command) and the configuration, to
[email protected]. For documentation issues, fill out the bug report form located at
https://www.juniper.net/cgi-bin/docbugreport/.
77
Revision History
12 November 2014—Revision 2, Junos OS Release 14.2R1– EX Series, M Series, MX Series,
PTX Series, and T Series.
5 November 2014—Revision 1, Junos OS Release 14.2R1– EX Series, M Series, MX Series,
PTX Series, and T Series.
Copyright © 2014, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, 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.
78

JUNOS OS 14.2 RELEASE NOTES ®

Transcription

Similar documents

February 2016 Growth Spurts

Junper Midrange Routing Solutons

Juniper Networks M-series : Product Overview

Accessing TP SSL VPN - Student

Juniper Parsoni

P4SC: Collaborative Design Presentation for Juniper Well Ranch

Hollywood Juniper

The New NeTwOrk fOr COllaBOraTION– OPTImIzINg UC&C DePlOYmeNT wITh