Release Notes 14.2R5

Release Notes 14.2R5
®
Release Notes: Junos OS Release 14.2R6
for the EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion
29 April 2016
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Junos OS Release Notes for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Bridging and Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Open vSwitch Database Management Protocol (OVSDB) . . . . . . . . . . . . 11
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Open vSwitch Database (OVSDB) Management Protocol . . . . . . . . . . . 16
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Copyright © 2016, Juniper Networks, Inc.
1
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Resolved Issues: Release 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Resolved Issues: Release 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Resolved Issues: Release 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Resolved Issues: Release 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Resolved Issues: Release 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 26
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 26
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Junos OS Release Notes for Junos Fusion Provider Edge . . . . . . . . . . . . . . . . . . . . 28
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Multicast Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Resolved Issues: Release 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Resolved Issues: Release 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Resolved Issues: Release 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Resolved Issues: Release 1.0R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Resolved Issues: Release 1.0R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 44
Basic Procedure for Upgrading an Aggregation Device . . . . . . . . . . . . . . 44
Upgrading an Aggregation Device with Redundant Routing Engines . . . 46
Preparing the Switch for Satellite Device Conversion . . . . . . . . . . . . . . . 47
Autoconverting a Switch into a Satellite Device . . . . . . . . . . . . . . . . . . . 48
Manually Converting a Switch into a Satellite Device . . . . . . . . . . . . . . . 50
2
Copyright © 2016, Juniper Networks, Inc.
Configuring a Switch into a Satellite Device Before Connecting It to a
Junos Fusion Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Configuring Satellite Device Upgrade Groups . . . . . . . . . . . . . . . . . . . . . 53
Converting a Satellite Device to a Standalone Device . . . . . . . . . . . . . . . 54
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 56
Downgrading from Release 14.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D
Universal Edge Routers, and T Series Core Routers . . . . . . . . . . . . . . . . . . . . 59
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authentication, Authorization and Accounting (AAA) (RADIUS) . . . . . . . 61
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Layer 2 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Operation, Administration, and Maintenance (OAM) . . . . . . . . . . . . . . . . 81
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 99
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Copyright © 2016, Juniper Networks, Inc.
3
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . 108
System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Resolved Issues: 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Resolved Issues: 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Resolved Issues: 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Resolved Issues: 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Resolved Issues: 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Adaptive Services Interfaces Feature Guide for Routing Devices . . . . . . 192
Broadband Subscriber VLANs and Interfaces Feature Guide . . . . . . . . 194
High Availability Feature Guide for Routing Devices . . . . . . . . . . . . . . . . 194
Monitoring, Sampling, and Collection Services Interfaces Feature Guide
for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
MPLS Applications Feature Guide for Routing Devices . . . . . . . . . . . . . 195
Overview for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide for
Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Services Interfaces Configuration Guide . . . . . . . . . . . . . . . . . . . . . . . . . 196
Subscriber Access Protocols Feature Guide . . . . . . . . . . . . . . . . . . . . . . 196
Subscriber Management Access Network Guide . . . . . . . . . . . . . . . . . . 197
Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Tunnel and Encryption Services Interfaces Feature Guide for Routing
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
User Access and Authorization Feature Guide for Routing Devices . . . . 198
4
Copyright © 2016, Juniper Networks, Inc.
VPNs Library for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . 199
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . 200
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . 202
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 202
Upgrading Juniper Network Routers Running Draft-Rosen Multicast
VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . 204
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled
for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Downgrading from Release 14.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Changes Planned for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Junos OS Release Notes for PTX Series Packet Transport Routers . . . . . . . . . . . 210
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Junos OS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Resolved Issues: 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Resolved Issues: 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Resolved Issues: 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Resolved Issues: 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Copyright © 2016, Juniper Networks, Inc.
5
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Resolved Issues: 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . 231
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 231
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . . 231
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Third-Party Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6
Copyright © 2016, Juniper Networks, Inc.
Introduction
Introduction
®
Junos OS runs on the following Juniper Networks hardware: ACX Series, EX Series, M
Series, MX Series, PTX Series, QFabric systems, QFX Series, SRX Series, T Series, and
Junos Fusion.
These release notes accompany Junos OS Release 14.2R6 for the EX Series, M Series,
MX Series, PTX Series, T Series, and Junos Fusion. 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.2R6 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 http://www.juniper.net/techpubs/software/junos/.
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R6 for the EX Series.
NOTE: The following EX Series platforms are supported in Junos OS Release
14.2R6: EX9200.
•
Hardware
•
Authentication and Access Control
•
Bridging and Learning
•
Class of Service
•
Interfaces and Chassis
•
Management
•
Network Management and Monitoring
•
Open vSwitch Database Management Protocol (OVSDB)
Copyright © 2016, Juniper Networks, Inc.
7
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
OpenFlow
•
Port Security
•
Routing Policy and Firewall Filters
•
Software Installation and Upgrade
•
User Interface and Configuration
•
VPNs
•
VXLAN
Hardware
•
8
New line cards for EX9200 switches—EX9200 switches support two new line cards.
These line cards interoperate with all existing line cards for EX9200 switches:
•
EX9200-6QS—6 40-Gigabit Ethernet QSFP+ ports that support 40GBASE-LR4 and
40GBASE-SR4 transceivers and 24 10-Gigabit Ethernet SFP+ ports that support
10GBASE-SR, 10GBASE-LR, 10GBASE-ER, and 10GBASE-ZR transceivers.
•
EX9200-40F-M—40 MACsec-capable 1-Gigabit Ethernet SFP ports that support
1000BASE-T, 10/100/1000BASE-T, 100BASE-FX, 1000BASE-EX, 1000BASE-LH,
1000BASE-LX, and 1000BASE-SX transceivers.
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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. Private VLANs are useful for restricting the flow of broadcast
and unknown unicast traffic and for limiting communication between known hosts.
Private VLANs 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 private VLAN 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.
[See Rewriting Packet Header Information on EX9200 Switches and Classifying Packets
by Behavior Aggregate on EX9200 Switches.]
Copyright © 2016, Juniper Networks, Inc.
9
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Interfaces and Chassis
•
Configuration support to improve MC-LAG Layer 2 and Layer 3 convergence
(EX9200)—Starting with Junos OS Release 14.2R3, you can configure multichassis
link aggregation (MC-LAG) interfaces on EX9200 switches to improve Layer 2 and
Layer 3 convergence times to subsecond values when an MC-AE link goes down or
comes up in a VLAN. To use this feature, ensure that the interchassis link (ICL) is
configured on an aggregated Ethernet interface.
For Layer 2 convergence, configure the enhanced-convergence statement on an
aggregated Ethernet interface at the [edit interfaces aex aggregated-ether-options
mc-ae] hierarchy level. For Layer 3 convergence, configure the enhanced-convergence
statement on an integrated routing and bridging (IRB) interface at the [edit interfaces
irb unit unit-number] hierarchy level.
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.]
Network Management and Monitoring
•
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.]
10
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
Open vSwitch Database Management Protocol (OVSDB)
•
OVSDB support (EX9200)—Starting with Junos OS Release 14.2, 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 and the reverse.
[See Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices and “Product Compatibility” on page 27.]
•
OVSDB schema update (EX9200)—Starting with Junos OS Release 14.2R4, the OVSDB
schema for physical devices version that is implemented on the EX9200 switch is
version 1.3.0. In addition, the schema now supports the multicast MACs local table.
[See Open vSwitch Database Schema For Physical Devices.]
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 enables 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 use the show openflow groups command to view
groups that were added, modified, or deleted from the group table by the OpenFlow
controller. 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, with the following features, is supported on EX9200 switches: 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 in messages
sent by the client to the server. This information can be used by the server to assign
addresses and configuration parameters to the client. The following options are
supported:
Copyright © 2016, Juniper Networks, Inc.
11
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Option 14, also known as Rapid Commit. When Rapid Commit is enabled, the DHCPv6
server and client use a two-message exchange (Solicit and Reply) to configure
clients, rather than the default four-message exchange (Solicit, Advertise, Request,
and Reply).
•
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.
•
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 37, also known as the Remote-ID option, is used to transmit information
about the remote host.
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.]
•
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 traverse a VLAN to all interfaces that are members of the VLAN.
This type of traffic forwarding 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.]
12
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
Routing Policy and Firewall Filters
•
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.]
Software Installation and Upgrade
•
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 supported on EX9200
switches on 10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet line
cards. Unified ISSU is a process to upgrade 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 identically to one performed through a cold boot.
Configure unified ISSU with the request system software in-service-upgrade command.
[See Unified ISSU System Requirements.]
User Interface and Configuration
•
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 make up the edge of the MPLS network. The CE
devices can 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 metro area networks (MANs) and
wide area networks (WANs).
[See EVPN Overview for Switches.]
Copyright © 2016, Juniper Networks, Inc.
13
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
VXLAN
•
VXLAN Gateway support (EX9200)—Starting with Junos OS Release 14.2, EX9200
switches support Virtual Extensible LAN (VXLAN) gateways. Each VXLAN gateway
supports the following functionalities:
•
32,000 VXLANs (with one VXLAN per bridge domain)
•
8000 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
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
Changes in Behavior and Syntax
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.2R6 for the EX Series.
•
Dynamic Host Configuration Protocol
•
Interfaces and Chassis
•
Network Management and Monitoring
•
Port Security
•
User Interface and Configuration
Dynamic Host Configuration Protocol
•
14
DHCP clients can send packets without Option 255 (EX9200)—On EX Series switches,
starting with Junos OS Release 14.2R2, you can override the default configuration of
the DHCP local server and enable clients to send DHCP packets that do not include
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
Option 255 (end-of-options). The default behavior in Junos OS is to drop packets that
do not include Option 255. To override that default behavior, configure the
allow-no-end-options CLI statement under the [system services dhcp-local-server
overrides] hierarchy level.
•
Format change for DHCP Option 18—On EX9200 switches with DHCP snooping
configured, when the VLAN ID is appended to the prefix of DHCP option 18, it appears
in decimal format instead of hexadecimal format.
Interfaces and Chassis
•
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.
Network Management and Monitoring
•
New system log message indicating the difference in the Packet Forwarding Engine
counter value (EX9200)—Effective in Junos OS Release 14.2R2, if the counter value
of a Packet Forwarding Engine is reported to be less than its previous value, then the
residual counter value is added to the newly reported value only for that specific counter.
In that case, the CLI shows the MIB2D_COUNTER_DECREASING system log message
for that specific counter.
Port Security
•
Enhanced output for show ethernet-switching interface extensive CLI
command—Starting with Junos OS Release 14.2, the output of the show
ethernet-switching interface extensive CLI command includes the fields VLAN members,
TAG, and STP state. The Logical interface flags field now includes STCL, which indicates
that the port is disabled because storm control is in effect, and MMAS, which indicates
that the port is disabled because the MAC address move limit has been exceeded.
User Interface and Configuration
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.
•
New and Changed Features on page 7
•
Known Behavior on page 16
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
Copyright © 2016, Juniper Networks, Inc.
15
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
Known Behavior
This section lists known behavior, system maximums, and limitations in hardware and
software in Junos OS Release 14.2R6 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.
•
Access Control
•
Interfaces and Chassis
•
Open vSwitch Database (OVSDB) Management Protocol
•
OpenFlow
•
Software Installation and Upgrade
•
VXLAN
Access Control
•
On EX9200 switches with 802.1X authentication enabled, if you associate an
802.1X-enabled interface in single-secure mode with a VLAN, when a client is
authenticated on that VLAN and then is later authenticated on a dynamic VLAN (a
guest VLAN or a VLAN assigned by a RADIUS server), the client might still be associated
with the interface-associated VLAN and receive the broadcast and multicast traffic
of that VLAN. PR955141
•
On EX9200 switches, if you configure a firewall filter name (filter name plus term name
plus counter name) that is longer than 128 characters, 802.1X (dot1x) authentication
might fail and cause the Network Processing Card (NPC) to crash. As a workaround,
configure the filter name, term name, and counter name such that when the total
length of those three names is added to the length of the interface name and the MAC
address, the total length does not exceed 128 characters. PR1083132
•
On EX9200 switches, the LLDP-MED bypass feature is not supported. PR1124537
Interfaces and Chassis
•
On EX9200 switches, traffic loss might occur for a few seconds (two through six
seconds) on the active node of an MC-LAG when the ICCP (Inter-Chassis Control
Protocol) goes down and then comes back. PR1107001
Open vSwitch Database (OVSDB) Management Protocol
•
16
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 that VMware NSX is running.) During this time, traffic
destined for this MAC address floods the VXLAN. PR962945
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
•
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
•
If 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
OpenFlow
•
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 support IPv6 specifications. Therefore,
the output for these fields typically displays None.
•
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, 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, if OpenFlow is enabled when you query
port information, the values for duration_nsec and duration_sec are always shown as
0. PR978321
•
On EX9200 switches running OpenFlow v1.3.1, flow statistics show packet flow as
increasing even when the output port link is down. PR987753
•
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
•
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 while an
OpenFlow interface is receiving line-rate traffic to which the default action packet-in
is applied, as it has no matching rule. PR892310
Copyright © 2016, Juniper Networks, Inc.
17
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Software Installation and Upgrade
•
On EX9200 switches, if you issue a unified ISSU from Junos OS Release 13.2 or earlier
to Junos OS Release 14.1 or later, approximately 20 seconds of traffic drop occurs for
IPv6 protocols (for example, OSPFv6, BGPv6, or RIPv6) that are enabled on integrated
routing and bridging (IRB) interfaces. The problem occurs because different link local
addresses have been generated in the two releases for the same IRB logical units. As
a workaround, configure different local IPv6 interfaces for different IRB logical units.
PR1086775
VXLAN
Related
Documentation
•
On EX9200 switches, IGMP snooping does not work on virtual tunnel endpoint (VTEP)
interfaces. PR989664
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R6
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.
•
Interfaces and Chassis
•
Network Management and Monitoring
•
Platform and Infrastructure
•
Software Installation and Upgrade
Interfaces and Chassis
•
On EX9200 switches, if you configure an interface range, if the interface range that
includes large-scale physical interfaces, and the family option is set to
ethernet-switching, the configuration might take a long time to commit. PR1072147
Network Management and Monitoring
•
18
On EX9200 switches, sFlow sampling might remain enabled after you have deleted
an sFlow sample-rate configuration from an interface. PR1075789
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On EX9200 switches, ingress sFlow samples of packets routed on an IRB interface
might be dropped, and an error message similar to the following might be displayed
for every drop: Sflow trinity_sflow_handle_packet, 145ifl 1245541 NULL. PR1147719
•
On EX9200 switches, an sFlow flow sample with an incorrect Frame Length value in
a raw packet header might be generated for frames larger than 128 bytes, because of
which, traffic volume calculated based on Frame Length and Sampling rate values in
the sFlow collector might be inaccurate. PR1152275
Platform and Infrastructure
•
On EX9200 switches, attempts by line cards to make unnecessary connections to the
Routing Engine might generate continuous debugging-level log messages, which
consume system resources. PR1113309
Software Installation and Upgrade
•
On EX9200 switches, all interfaces on 1-Gigabit line cards with copper SFPs might flap
during a unified ISSU. The unused ports might flap as well. One or more interfaces
might flap on a 10-Gigabit line card with 32 ports in an MC-LAG/LACP configuration.
PR1007038
Related
Documentation
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
Resolved Issues
This section lists the issues fixed in the 14.2 Junos OS main release and the maintenance
releases.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
Resolved Issues: Release 14.2R6 on page 20
•
Resolved Issues: Release 14.2R5 on page 20
•
Resolved Issues: Release 14.2R4 on page 21
•
Resolved Issues: Release 14.2R3 on page 22
•
Resolved Issues: Release 14.2R2 on page 24
Copyright © 2016, Juniper Networks, Inc.
19
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Resolved Issues: Release 14.2R6
Authentication and Access Control
•
On an EX9200 switch acting as a DHCPv6 server, the server does not send a Reply
packet on receiving a Confirm packet from the client; the behavior is not compliant
with the RFC3315 standard. PR1025019
Interfaces and Chassis
•
On EX9200 switches, an IRB unicast next hop in a scenario with a Layer 2 LAG as the
underlying interface might result in traffic blackholing. PR1114540
Resolved Issues: Release 14.2R5
•
Access Control and Authentication
•
Dynamic Host Configuration Protocol
•
Firewall Filters
•
Interfaces and Chassis
•
Network Management and Monitoring
•
Platform and Infrastructure
•
Routing Protocols
Access Control and Authentication
•
On EX9200 switches, RADIUS authentication might fail if the switch receives an
Access-Accept message containing a Cisco vendor-specific attribute (VSA). PR1095197
Dynamic Host Configuration Protocol
•
On EX9200 switches, DHCP snooping and related access security features of ARP
inspection, IP source guard, neighbor discovery inspection and IPv6 source guard are
not supported at the [edit logical-systems logical-system-name vlans vlan-name
forwarding-options dhcp-security] hierarchy level. PR1087680
•
On EX9200 and QFX5100 switches, if you configure DHCP relay with the DHCP server
and the DHCP client in separate routing instances, unicast DHCP reply packets, such
as a DHCPACK message in response to a DHCPRENEW message, might be dropped.
PR1079980
20
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Firewall Filters
•
On EX9200 switches, 32k is the minimum value that you must configure for policer
bandwidth limits. If you configure a policer bandwidth limit that is less than 32k, an
error message is displayed. PR1109780
Interfaces and Chassis
•
On EX9200 switches, a remote attacker can make a denial-of-service attack by using
maliciously crafted uBFD packets that are received directly through VPN, MPLS, and
multicast or broadcast traffic, and on Virtual Tunnel (VT) interfaces, or otherwise. This
issue affects both IPv4 and IPv6 traffic in Ethernet environments where the crafted
packet is received over physical interfaces. PR1102581
Network Management and Monitoring
•
On EX9200 switches, if you configure an invalid interface address as the SNMP source
address, SNMP traps might not be sent even after you change the SNMP source address
to a valid interface address. As a workaround, restart the snmpd process. PR1099802
Platform and Infrastructure
•
On EX9200 switches with MPC3E/MPC4E line cards installed, if you enable the flow
detection feature at the [edit system ddos-protection] hierarchy level, suspicious control
flow might not be detected on the line cards; or, if the suspicious control flows are
detected, they might never time out, even if the traffic flows no longer violate the
control parameters. PR1102997
Routing Protocols
•
On EX9200 switches operating in a routing domain with a PIM-embedded IPv6
rendezvous point (RP), accessing the RP after the memory is freed might cause the
routing protocol process to generate a core file. PR1101377
Resolved Issues: Release 14.2R4
•
Interfaces and Chassis
•
Layer 2 Features
Interfaces and Chassis
•
On EX9200 switches, the Dynamic Host Configuration Protocol (DHCP) relay feature,
which allows the client interface and the server interface to be in separate virtual
routing and forwarding (VRF) instances, does not work if the client interface is
configured as an integrated routing and bridging (IRB) interface. PR1064889
•
On EX9200 switches, if DHCP relay is configured using the forward-only and
forward-only-replies statements at the [edit forwarding-options dhcp-relay] hierarchy
level, and the DHCP local server is configured with the forward-snooped-clients
statement at the [edit system services dhcp-local-server] hierarchy level, then the
configuration for forward-snooped-clients takes precedence over the configuration for
forward-only and forward-only-replies. As a result, DHCP message exchange between
Copyright © 2016, Juniper Networks, Inc.
21
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
VRF instances might not work as expected. As a workaround, do not configure
forward-only and forward-only-replies together with forward-snooped-clients. PR1077016
•
On EX9200 switches, the unsupported auto-10m-100m option no longer appears in
the CLI. PR1077020
•
On EX9200 switches, if you configure an MC-LAG with two devices, and then delete
and re-create an MC-AE interface, broadcast and multicast traffic that is flooded might
loop for several milliseconds. PR1082775
•
On EX9200 switches, if you configure a virtual private LAN service (VPLS), no
label-switched interface (LSI) belongs to a VLAN even though the VPLS connection
is in the UP state, and traffic does not flood to an LSI. As a workaround, configure VPLS
on the routing instance instead of on the virtual-switch instance. PR1083561
•
An EX9200-40F-M line card drops all traffic on an IRB logical interface, including both
data plane and control plane traffic. If an IRB logical interface is configured on an
EX9200-40F-M line card as part of a VLAN, any device connected through that interface
cannot use Layer 3 forwarding outside the subnet, because EX9200-40F-M does not
handle the ARP function correctly. Configuring static ARP on devices using the EX9200
as a gateway is not a workaround, because packets are still dropped if the Routing
Engine of the EX9200 has the routes and the ARP entry for the destination IP.
PR1086790
•
On EX9200 switches, if you add a VLAN on an existing virtual-switch instance for virtual
private LAN service (VPLS), the label-switched interface (LSI) might not be associated
with the new VLAN. PR1088541
Layer 2 Features
•
On EX9200 switches, if you configure a virtual private LAN service (VPLS) routing
instance and then add interfaces to that VPLS routing instance, the system might
create a core file and go into db (debug) mode, because the addition of the interfaces
to the routing instance caused a buffer overflow. PR1068898
Resolved Issues: Release 14.2R3
•
Access Control and Authentication
•
Dynamic Host Configuration Protocol
•
Firewall Filters
•
Interfaces and Chassis
•
Layer 2 Features
•
OpenFlow
•
Platform and Infrastructure
•
Routing Protocols
Access Control and Authentication
•
22
On EX9200 switches, the output for the ptopoConnRemotePort MIB might display an
incorrect value for portIDMacAddr. PR1061073
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On EX9200 switches, when clients are authenticated with dynamic VLAN assignment
on an 802.1X-enabled interface, disabling 802.1X authentication on that interface
might cause the Layer 2 Address Learning daemon (l2ald) to generate a core file.
PR1064491
Dynamic Host Configuration Protocol
•
On EX9200 switches with DHCPv6 snooping configured, if the Juniper Enterprise ID
(2636) is included in the prefix of DHCPv6 option 37 (Remote ID) or DHCPv6 option
16 (Vendor Class ID), the Juniper Enterprise ID will be encoded in binary. The DHCPv6
options are appended to DHCPv6 packets if DHCPv6 snooping is configured on the
switch. PR1052956
Firewall Filters
•
On EX9200 switches, after you upgrade Junos OS to Release 14.1R1 or a later release,
configuring ipv6-payload-protocol as a firewall filter match condition might cause the
related filters to stop working. PR1066725
Interfaces and Chassis
•
On EX9200 switches, when the switch receives LACP control packets from an interface
other than an aggregated Ethernet (AE) interface, it forwards the packets, causing
LACP peer devices that receive the packets to reset the LACP connections. This might
cause continuous flaps for all AE or multichassis aggregated Ethernet (MC-AE)
interfaces. PR1034917
•
On EX9200 switches, although the minimum Junos OS release that supports the
EX9200-6QS line card is Release 14.2R1, if an IRB logical interface is configured on an
EX9200-6QS line card as part of a VLAN, any device connected through that interface
is unable to route outside of the subnet because EX9200-6QS drops all ARP requests.
As a result, the EX9200-6QS line card drops all routed traffic, including both data
plane and control plane traffic. Configuring static ARP on devices that use an EX9200
switch as gateway is not a workaround because the packets are still dropped if the
Routing Engine of the EX9200 has the routes and ARP entry for the destination IP. As
a workaround, upgrade your software to the release specified in TSB16659 if your switch
configuration includes an IRB logical interface configured on an EX9200-6QS line card
as part of a VLAN. PR1055566
•
On EX9200 switches, if a 100-gigabit interface is configured as part of a Link
Aggregation Group (LAG), committing any configuration change causes the interface
to flap. PR1065512
Copyright © 2016, Juniper Networks, Inc.
23
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Layer 2 Features
•
On EX9200 switches, if MVRP is configured on an aggregated Ethernet (AE) interface,
MVRP might become unstable if the CLI command no-attribute-length-in-pdu is
configured. PR1053664
OpenFlow
•
On EX9200 switches running OpenFlow v1.3.1, the switching device stops responding
if an interface goes down when the echo interval timeout is set to less than 11 seconds.
PR989308
Platform and Infrastructure
•
On EX9200 switches, if the switch receives a BFD control packet that is larger than 52
bytes, the BFD process might create a core file. PR1004482
•
On EX9200 switches, recurring local memory (LMEM) data errors might cause a chip
wedge. PR1033660
•
On EX9200 switches, when the switch is configured as a DHCP relay agent with option
82, and the circuit ID is configured with the CLI statement use-interface-description
with the device option, then the string of the option 82 field in the DHCP DISCOVER
message that is forwarded to the DHCP server must include the switch name, physical
interface name, and the VLAN name. However, the string contains integrated routing
and bridging (IRB) information in place of the physical interface name. PR1037687
•
On EX9200 switches, a process that fails multiple times in a short period of time might
not generate a core file. PR1058192
Routing Protocols
•
On EX9200 switches on which virtual private LAN service (VPLS) is enabled, if the
interfaces on the CE device belong to multiple FPCs, traffic might keep flooding the
VPLS routing-instance for more than 2 seconds during the MAC learning phase when
the links between the PE device and the CE device flap, or when the administrator
clears the VPLS MAC table. PR1031791
Resolved Issues: Release 14.2R2
•
Dynamic Host Configuration Protocol
•
Infrastructure
•
Interfaces and Chassis
•
Spanning-Tree Protocols
Dynamic Host Configuration Protocol
•
On EX9200 switches, the DHCPv6 binding table as shown in the output of the show
dhcp-security ipv6 binding might contain stale entries under the following conditions:
1.
24
There is a mismatch in the link local address between the link local binding and the
dynamic binding.
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
2. There is no dynamic binding, and a SOLICIT message that matches the link local
entry is received, causing the state of the IPv6 address to transition from BOUND
to WAITING. This resets the lease timer and creates a stale entry.
The presence of stale entries in the DHCPv6 binding table might cause the jdhcpd
process to create a core file. PR1012556
•
On EX9200 switches, Dynamic Host Configuration Protocol (DHCP) relay functionality
might stop working and DHCP does not form new bindings if the number of subscribers
exceeds 1000. PR1033921
Infrastructure
•
On EX9200 switches, if the switch receives an ARP packet while the forwarding
information base (FIB) has exceeded the limit of 262144 routes, the kernel might
generate a core file. PR1028714
Interfaces and Chassis
•
On EX9200 switches, in an MC-LAG scenario, a MAC address might incorrectly point
to an inter-chassis control link (ICL) after a MAC move from a single-home LAG to the
MC-LAG. PR1034347
Spanning-Tree Protocols
Related
Documentation
•
On EX9200 switches running the VLAN Spanning Tree Protocol (VSTP), incoming
BPDUs might not be included in the output of the show spanning-tree statistics interface
command. PR847405
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
Documentation Updates
There are no errata or changes in Junos OS Release 14.2R6 for the EX Series switches
documentation.
Related
Documentation
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
Copyright © 2016, Juniper Networks, Inc.
25
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Resolved Issues on page 19
•
Migration, Upgrade, and Downgrade Instructions on page 26
•
Product Compatibility on page 27
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 26
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.
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
26
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Product Compatibility on page 27
Copyright © 2016, Juniper Networks, Inc.
Product Compatibility
Product Compatibility
•
Software Compatibility on page 27
•
Hardware Compatibility on page 27
Software Compatibility
The Juniper Networks implementation of OVSDB on the EX9200 switch is supported
with the following VMware NSX versions:
•
Starting with Junos OS Release 14.2R1, NSX version 4.0.3.
•
Starting with Junos OS Release 14.2R2, NSX version 4.2 and later versions.
The Juniper Networks implementation of OVSDB on the EX9200 switch supports the
following OVSDB schema for physical devices versions:
•
Starting with Junos OS Release 14.2R1, OVSDB schema version 1.11.90. This schema
version is compatible with NSX version 4.0.3.
•
Starting with Junos OS Release 14.2R4, OVSDB schema version 1.3.0. This schema
version is compatible with NSX version 4.0.3 and with NSX version 4.2 and later.
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
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 14
•
Known Behavior on page 16
•
Known Issues on page 18
•
Resolved Issues on page 19
•
Documentation Updates on page 25
•
Migration, Upgrade, and Downgrade Instructions on page 26
Copyright © 2016, Juniper Networks, Inc.
27
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Junos OS Release Notes for Junos Fusion Provider Edge
These release notes accompany Junos OS Release 14.2R6 for the Junos Fusion.
You can also find these release notes on the Juniper Networks Junos OS Documentation
webpage, located at http://www.juniper.net/techpubs/software/junos/.
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R6. for Junos Fusion Provider Edge.
•
Junos Fusion on page 28
•
Class of Service (CoS) on page 31
•
Interfaces on page 31
•
Layer 2 Protocols on page 34
•
Layer 3 Protocols on page 34
•
Multicast Protocols on page 35
•
Network Management and Monitoring on page 35
•
Software Installation and Upgrade on page 36
•
VPNs on page 37
Junos Fusion
•
Junos Fusion support (MX Series routers, QFX5100 switches, and EX4300
switches)—Starting with Junos OS Release 14.2R3, Junos OS supports a network
system named Junos Fusion. Based on the 802.1BR standard, Junos Fusion is a
combination of aggregation devices and satellite devices that appear to the rest of the
network as a single device. Junos Fusion expands the port density of the aggregation
device and allows it to send and receive traffic using the customer-facing ports of the
directly connected satellite devices. The composite of the aggregation device and
satellite devices–Junos Fusion–is configured and managed through the aggregation
device.
You can configure the following MX Series routers as an aggregation device:
28
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
MX80 routers
•
MX104 routers
•
MX240 routers
•
MX480 routers
•
MX960 routers
•
MX2010 3D Universal Edge Routers
•
MX2020 3D Universal Edge Routers
You can configure the following switches as satellite devices:
•
QFX5100 switches—QFX5100-24Q-2P, QFX5100-48S-6Q, QFX5100-48T-6Q, and
QFX5100-96S-8Q
•
EX4300 switches—EX4300-24P, EX4300-24T, EX4300-32F, EX4300-48P,
EX4300-48T, and EX4300-48T-BF
[See Junos Fusion Overview.]
•
Extended satellite device support (EX4300-32F switch)—Starting with Junos OS
Release 14.2R5, an EX4300-32F switch can be converted for use as a satellite device
in a Junos Fusion topology. You must upgrade the switch to Junos OS Release
14.1X53-D30 or later before you convert it into a satellite device, the MX Series
aggregation device must run Junos OS Release 14.2R5 or later, and the satellite device
package must be version 1.0R2 or later.
•
Extended aggregation device support (MX80 and MX104 routers)---Starting with
Junos OS Release 14.2R6, the MX80 and MX104 3D Universal Edge Routers can be
used as aggregation devices in a Junos Fusion Provider Edge topology.
•
Environment monitoring satellite policies (Junos Fusion)—Starting with Junos OS
Release 14.2R3, Junos Fusion allows you to configure environment monitoring satellite
policies to define how environmental events on satellite devices, such as link-down
alarms, are handled in Junos Fusion. To configure an environment monitoring satellite
policy, include the environment-monitoring-policy statement in the [edit policy-options
satellite-policies] hierarchy level.
•
New and enhanced chassis commands (Junos Fusion)—Starting with Junos OS
Release 14.2R3, several new show chassis commands are available and several existing
show chassis commands have been enhanced to display output related to Junos Fusion
operations. The following new commands are now available to support Junos Fusion:
•
show chassis satellite
•
show chassis satellite extended-port
•
show chassis satellite interface
•
show chassis satellite neighbor
•
show chassis satellite software
•
show chassis satellite statistics
Copyright © 2016, Juniper Networks, Inc.
29
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
show chassis satellite unprovision
•
show chassis satellite upgrade-group
The following existing commands have been enhanced to include the satellite option
to display information about a Junos Fusion topology:
•
•
30
•
show chassis alarms
•
show chassis environment
•
show chassis environment fpc
•
show chassis environment pem
•
show chassis environment routing-engine
•
show chassis fan
•
show chassis firmware
•
show chassis hardware
•
show chassis led
•
show chassis routing-engine
•
show chassis temperature-thresholds
Enhanced system commands (Junos Fusion)—Starting with Junos OS Release 14.2R3,
several existing request system commands have been enhanced to support software
installation and file management procedures for Junos Fusion. The following existing
request system commands have been enhanced to support Junos Fusion:
•
request system software add
•
request system software delete
•
request system software rollback
•
request system storage cleanup
Additional MPC support (MX Series routers)—Starting with Junos OS Release 14.2R6,
the following Modular Port Concentrators (MPCs) are supported as Junos Fusion
Provider Edge cascade ports on MX240, MX480, MX960, MX2010, and MX2020 routers:
•
MPC2E NG
•
MPC2E NG Q
•
MPC3E NG
•
MPC3E NG Q
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
Class of Service (CoS)
•
CoS support (Junos Fusion)—Starting with Junos OS Release 14.2R3, Junos Fusion
supports the standard Junos OS CoS features and operational commands. Each
extended port on a satellite device is a logical extension to the aggregation device.
Therefore, the default CoS policy on the aggregation device applies to each extended
port. You can also create standard CoS policies for extended ports.
A cascade port is a physical port or interface on an aggregation device that provides
a connection to a satellite device. Port scheduling is supported on cascade ports. Junos
Fusion technology reserves a separate set of queues with minimum bandwidth
guarantees for in-band management traffic to protect against congestion caused by
data traffic.
Support for configuring enhanced transmission selection (ETS) is also extended to
MX Series routers for satellite device ports that support ETS. If ETS is configured on
the MX Series aggregation device for a satellite device port that does not support ETS,
the satellite device converts the ETS configuration to a port scheduler.
[See Understanding CoS on an MX Series Aggregation Device in Junos Fusion.]
Interfaces
•
Supported port types (Junos Fusion)—Starting with Junos OS Release 14.2R3, Junos
Fusion supports the following port types:
•
Cascade port—Provides a connection to a satellite device. Cascade ports on an
aggregation device connect to uplink ports on the satellite device.
•
Uplink port—Provides a connection to an aggregation device. Uplink ports on a
satellite device connect to cascade ports on the aggregation device.
•
Extended port—Provides a connection to servers or endpoints. Extended ports are
the physical interfaces of the satellite devices. The satellite devices appear as
additional FPCs on the aggregation device in a Junos Fusion topology, and extended
ports appear as additional interfaces to be managed by the aggregation device.
[See Understanding Junos Fusion Ports.]
•
Uplink failure detection (Junos Fusion)—Starting with Junos OS Release 14.2R3, Junos
Fusion enables satellite devices to detect link failures on the uplink interfaces used to
connect to aggregation devices. When a host device is multihomed to two satellite
devices, and one of the uplink interfaces goes down, the host device can redirect traffic
through the other active satellite device. All of the extended ports configured on the
satellite device with the uplink interface failure are shut down.
By default, UFD is disabled. To enable UFD for all satellite devices, include the
uplink-failure-detection statement at the [edit chassis satellite-management] hierarchy
level. To enable UFD for specific satellite devices, include the uplink-failure-detection
statement at the edit chassis satellite-management fpc] hierarchy level.
EX4300 and QFX5100 switches configured as satellite devices have a default set of
uplink interfaces.Table 1 on page 32 shows the default set of uplink interfaces that
UFD selects for failure detection:
Copyright © 2016, Juniper Networks, Inc.
31
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Table 1: UFD Default Uplink Interfaces for Satellite Devices
Device Type
Default Uplink Interfaces
EX4300-24P (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
EX4300-24T (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
EX4300-32F (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
EX4300-48P (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
EX4300-48T (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
EX4300-48T-BF (4 ports each on PIC1 and PIC2)
1/0 through 1/3 and 2/0 through 2/3
QFX5100-24Q-2P
0/0 through 0/3
QFX5100-48S-6Q (6 QSFP+ ports)
0/48 through 0/53
QFX5100-48T-6Q (6 QSFP+ ports)
0/48 through 0/53
QFX5100-96S-8Q (8 QSFP+ ports)
0/96 through 0/103
If you choose not to use the default set of uplinks for your satellite devices, you need
to specify which uplink interfaces you want to use for UFD. To apply UFD to an uplink
interface, include the ufd-default-policy statement at the [edit chassis
satellite-management uplink-failure-detection] hierarchy level. You also need to
configure the UFD policy. For example:
[edit policy-options]
satellite-policy {
candidate-uplink-port-profile {
ufd-default-policy {
term qfx5100 {
product-model QFX5100*;
uplink-port-group uplink-ports;
}
}
}
port-group-alias {
uplink-ports {
pic 0 {
port [1, 2];
}
pic 1 {
port [3,4];
}
}
}
}
[See Overview of Uplink Failure Detection on a Junos Fusion.]
32
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
Increasing number of aggregated Ethernet interfaces to approximately 1000 (Junos
Fusion)—Starting with Junos OS Release 14.2R3, aggregation devices support up to
1000 aggregated Ethernet interfaces, depending on the number satellite devices
included in a Junos Fusion topology.
•
LACP support (Junos Fusion)—Starting with Junos OS Release 14.2R3, LACP is
supported on Junos Fusion. It provides the ability to bundle several physical interfaces
to form one logical aggregated Ethernet interface. The LACP mode can be active or
passive. The transmitting link is known as the actor, and the receiving link is known as
the partner. If the actor and partner are both in passive mode, they do not exchange
LACP packets, and the aggregated Ethernet links do not come up. If either the actor
or partner is active, they do exchange LACP packets. By default, LACP is in passive
mode on aggregated Ethernet interfaces. To initiate transmission of LACP packets and
response to LACP packets, you must enable LACP active mode.
You can configure Ethernet links to actively transmit PDUs, or you can configure the
links to passively transmit them, sending out LACP PDUs only when they receive them
from another link.
[See Understanding Link Aggregation and Link Aggregation Control Protocol in a Junos
Fusion]
•
MC-LAG support (Junos Fusion)—Starting with Junos OS Release 14.2R3, you can
configure MC-LAG between two aggregation devices in a Junos Fusion topology.
You can also configure MC-LAG interfaces to improve the Layer 2 and Layer 3
convergence time when a MC-LAG Ethernet link goes down or comes up. To configure
enhanced convergence, issue the enhanced-convergence statement at the [edit
interfaces ae aggregated-ether-options mc-ae] hierarchy level for an aggregated Ethernet
interface and at the [edit interfaces irb unit unit-number] hierarchy level for an IRB
interface.
[See Understanding Multichassis Link Aggregation in a Junos Fusion.]
•
Configuration synchronization for MC-LAG (Junos Fusion)---Starting with Junos OS
Release 14.2R6, Junos Fusion supports the ability to easily propagate, synchronize, and
commit configurations from one MC-LAG peer to another MC-LAG peer. MC-LAG
configuration synchronization enables you log into any one of the MC-LAG peers to
manage both MC-LAG peers, thus having a single point of management. With MC-LAG
configuration synchronization, you can use configuration groups to simplify the
configuration process. For example, you can create configuration groups for the local
MC-LAG peers, one for the remote MC-LAG peer, and one for the global configuration,
which is essentially a configuration that is common to both MC-LAG peers. You can
create conditional groups to specify when a configuration is synchronized with another
MC-LAG peer. Additionally, you can enable the peers-synchronize command at the
[edit system commit] hierarchy to synchronize the configurations and commits across
the MC-LAG peers by default. NETCONF over SSH provides a secure connection
between the MC-LAG peers, and Secure Copy Protocol (SCP) copies the configurations
securely between the MC-LAG peers.
•
Enhanced interface commands (Junos Fusion)—Starting with Junos OS Release
14.2R3, Junos Fusion provides information for extended ports and uplink ports on
satellite devices through operational mode commands and output. Extended port
Copyright © 2016, Juniper Networks, Inc.
33
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
names include the extended FPC slot number, PIC slot, and port number. For example,
a 10-Gigabit Ethernet extended port number might be xe-125/1/8, where 125 is the FPC
slot number, 1 is the physical interface card (PIC) slot, and 8 is the extended port
number.
The following commands have been enhanced to display the extended ports and
uplink ports by using either the slot or the alias. Additionally, you can now use the
keyword satellite to view information about the satellite device ports:
•
show interfaces satellite-device (all | alias)
•
show interfaces extensive satellite-device (all | alias)
•
show interfaces terse satellite-device (all | alias)
Layer 2 Protocols
•
RSTP configuration supports 1024 VLAN instances on extended ports for MX Series
platforms (Junos Fusion)—Starting with Junos OS Release 14.2R4, Junos Fusion
supports up to 1024 VLAN instances for the Rapid Spanning Tree Protocol (RSTP) on
MX Series platforms for improved scalability. Typically each VLAN corresponds with
an associated spanning tree, which affects processing resources due to the number
of VLANs. Increasing the number VLAN instances helps increase scalability across the
MX Series platform.
Layer 3 Protocols
•
Support for Layer 3 protocols (Junos Fusion)—Starting with Junos OS Release 14.2R4,
many of the routing protocols supported on MX Series routers have been extended to
the satellite devices in a Junos Fusion topology. You can configure the following Layer
3 routing protocols on satellite device extended ports:
•
BGP
•
BGP for IPv6
•
IS-IS
•
IS-IS for IPv6
•
OSPF
•
OSPF version 3
You can configure the following Layer 3 routing protocols on satellite device extended
ports that are included in LAGs and MC-LAGs:
34
•
BGP
•
IS-IS
•
OSPF
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
[See Junos Fusion Protocol Support.]
Multicast Protocols
•
Support for multicast protocols (Junos Fusion)—Starting with Junos OS Release
14.2R4, many of the multicast protocols supported on MX Series routers have been
extended to the satellite devices in a Junos Fusion topology. You can configure the
following multicast protocols on satellite device extended ports:
•
IGMP
•
MLD
•
PIM source-specific multicast (SSM)
•
PIM sparse mode
[See Junos Fusion Protocol Support.]
Network Management and Monitoring
•
Chassis MIB support (Junos Fusion)—Starting with Junos OS Release 14.2R3, satellite
devices in a Junos Fusion topology are represented in the chassis MIB. Satellite devices
are represented as FPC slots (100, 101,102,..) in the aggregation device. The support is
enabled using a range of container indexes, which enable the SNMP process to redirect
SNMP requests to the chassis process or SPMD based on the first index entry.
The following tables have been implemented for satellite devices:
•
jnxContainersTable
•
jnxContentsTable
•
jnxFilledTable
•
jnxOperatingTable
•
jnxFRUTable
These tables have an index consisting of four entries–CIDX, L1, L2, and L3–where CIDX
is the container index, L1 is the level-1 index (slot), L2 is the level-2 index (component
within the L1 slot), and L3 is the level-3 index (subcomponent of the L2 slot). For
example, an entry of 104.101.2.0 would indicate CIDX 104 is the index for fans and refers
to the second fan of satellite device 100 (all indexes are 1-based). The CIDX indexes
for Junos Fusion are offset by 100 from regular indexes; for example, a regular CIDX 2
(power supply) is 102 for the power supply of the satellite device. Using these indexes,
you can distinguish the satellite device hardware from the aggregation device hardware.
[See Chassis MIB Support (Junos Fusion).]
•
Satellite device system log messages (Junos Fusion)—Starting with Junos OS Release
14.2R3, Junos Fusion generates system log messages for the following major events
on satellite devices:
•
Satellite device discovery
•
Satellite device offline
Copyright © 2016, Juniper Networks, Inc.
35
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Satellite device software upgrade success or failure
•
Satellite device extended port up/down
•
Satellite device extended port addition/deletion failures
•
Satellite device extended port link down alarms raised/cleared
•
Satellite device power supply addition/removal
•
Satellite device fan addition/removal
•
Satellite device chassis alarms raised/cleared
Software Installation and Upgrade
•
Upgrading and managing the satellite software on satellite devices (Junos
Fusion)—Starting with Junos OS Release 14.2R3, Junos Fusion provides the ability to
manage satellite software. To convert a standalone switch to a satellite device, you
can use one of the following methods:
•
Autoconversion—Automatically converts a standalone device into a satellite device
when it is cabled to a cascade port on the aggregation device.
•
Manual conversion—Installs satellite software manually from the aggregation device
using the request chassis satellite interface interface-name device-mode satellite
command.
•
Preconversion—Installs satellite software onto a device before connecting it to a
Junos Fusion topology.
After you convert the switch to a satellite device, you can install satellite software
upgrades onto a satellite device through the aggregation device.
Satellite software upgrade groups are often needed to install satellite software. A
satellite software upgrade group is a group of satellite devices that are designated to
upgrade to the same satellite software version using the same satellite software
package. When you add a satellite to an upgrade group that is not running the same
satellite software, the satellite device is automatically updated to the version of satellite
software associated with the upgrade group.
You can use the following commands to add and associate a satellite software version
with an upgrade group:
•
request system software add upgrade-group—Add the satellite software and associate
it with the specified upgrade group.
•
request system software delete upgrade-group—Remove the satellite software
association from the specified upgrade group.
•
request system software rollback upgrade-group—Associate an upgrade group with
a previous version of satellite software.
You can issue the show chassis satellite software command to see which software
images are stored on the aggregation device and which upgrade groups are associated
with the software images.
36
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
[See Understanding Junos Fusion Components, Understanding Software in a Junos Fusion,
and Configuring Junos Fusion.]
VPNs
•
Support for VPNs (Junos Fusion)—Starting with Junos OS Release 14.2R4, many of
the VPN protocols supported on MX Series routers have been extended to the satellite
devices in a Junos Fusion topology. You can configure satellite device extended ports
as CE router interfaces for the following VPNs:
•
Layer 2 circuits
•
Layer 2 VPNs
•
Layer 3 VPNs
•
Logical routers
•
Virtual private LAN service (VPLS)
[See Junos Fusion Protocol Support.]
Related
Documentation
•
EVPN and VXLAN support (Junos Fusion)—Starting with Junos OS Release 14.2R6,
Junos Fusion extends the use of EVPN with VXLAN encapsulation to satellite devices
managed by MX Series routers. This feature provides Layer 2 connectivity for end
stations within a virtualized network. The end stations consist of virtual hosts connected
to the virtualized server, and nonvirtualized bare metal servers connected to top-of-rack
switches. The MX Series routers also function as default gateways for the internetwork
traffic among end stations that belong to different virtual networks.
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Changes in Behavior and Syntax
This section lists the changes in behavior of Junos OS features and changes in the syntax
of Junos OS statements and commands in Junos OS Release 14.2R6 or later for Junos
Fusion Provider Edge.
Junos Fusion
•
Default configuration statement now implicit (Junos Fusion)—Starting in Junos OS
Release 14.2R5, the single-home statement at the [edit chassis satellite-management]
hierarchy level is now both the default value and implicit. The statement becomes
automatically configured when you include any portion of the [edit chassis
Copyright © 2016, Juniper Networks, Inc.
37
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
satellite-management] hierarchy level in your Junos Fusion configuration. As a result,
all satellite devices are single-homed by default and the single-home statement does
not need to be configured explicitly. However, for backward compatibility reasons, the
single-home configuration statement is still supported for legacy configurations.
Related
Documentation
•
Support for the satellite all option across multiple user classes (Junos
Fusion)---Starting in Junos OS Release 14.2R6, you can now include the satellite all
statement at the [edit system login class class-name] hierarchy level for multiple classes.
When you assign a class containing the satellite all privilege to a user, the user can
access a satellite device from an aggregation device without re-entering user
credentials, such as username and password.
•
Evolution of satellite device user privileges (Junos Fusion)—When you assign the
following privileges to a user, the user can log in to a satellite device from an aggregation
device per software release as described:
•
Junos OS Release 14.2R3: The root user can log in without a password, and users
with class satellite all can log in with a password.
•
Junos OS Release 14.2R5: The root user, super-user, and users with class satellite all
can log in without a password.
•
Junos OS Release 14.2R6: The root user, super-user, and users with class satellite
all, permissions all, and permissions maintenance can log in without a password.
•
New and Changed Features on page 28
•
Known Behavior on page 38
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Known Behavior
This section lists known behavior, system maximums, and limitations in hardware and
software in Junos OS Release 14.2R6 for Junos Fusion Provider Edge.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
Junos Fusion
38
•
On a Junos Fusion Provider Edge topology, if you attempt to implement MAC filtering
or MAC accounting on extended ports, the features might not work. PR1023578
•
On a Junos Fusion Provider Edge topology running 32-bit Junos OS, if you configure an
aggregation device with nonstop active routing, and the aggregation device processes
more than 150,000 routes, the standby Routing Engine might lose its connection to
Copyright © 2016, Juniper Networks, Inc.
Known Issues
the master Routing Engine. As a workaround, verify that the aggregation device Routing
Engine is compatible with the 64-bit Junos OS, and then upgrade it to the 64-bit version.
PR1068157
Related
Documentation
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R6
for Junos Fusion Provider Edge.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
Junos Fusion
•
On a Junos Fusion Provider Edge topology, if you configure an outgoing firewall or
policer to drop packets prior to transmission, the logical interfaces of satellite device
extended ports that appear in the output of the show interfaces extensive command
might include packets in the statistics counter that have been dropped but not
forwarded. PR1078304
•
On a Junos Fusion Provider Edge topology, if you enable MC-LAG over an IRB interface
and perform a graceful Routing Engine switchover, the system might experience traffic
loss of up to 60 percent of the traffic for 90 seconds and a drop in the ARP count.
PR1080192
•
On a Junos Fusion Provider Edge topology running multicast, if you disable and reenable
a satellite device, the PIM upstream interface state might not be updated correctly.
PR1091449
•
On a Junos Fusion Provider Edge topology running multicast, if you delete multicast
routes from native aggregation device ports and extended ports, the PIM join (s,g)
states might still appear in the output of the show pim join summary command.
PR1092192
•
On a Junos Fusion Provider Edge topology, when unicast next hops for the satellite
device extended ports are deleted and added, if the routing chip memory is not freed,
a small memory leak occurs during the next-hop deletion. If the churn happens for an
Copyright © 2016, Juniper Networks, Inc.
39
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
extended period, the Flexible PIC Concentrator (FPC) might run out of memory and
stop operating. PR1114369
Related
Documentation
•
On a Junos Fusion Provider Edge topology, when you issue the show chassis satellite
device-alias ? command, the list of available satellite devices is not displayed. PR1148762
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Resolved Issues
This section lists the issues fixed in the Junos OS Release 14.2R4. for Junos Fusion Provider
Edge.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
Resolved Issues: Release 14.2R6 on page 40
•
Resolved Issues: Release 14.2R5 on page 41
•
Resolved Issues: Release 14.2R4 on page 42
•
Resolved Issues: Release 1.0R3 on page 42
•
Resolved Issues: Release 1.0R2 on page 42
Resolved Issues: Release 14.2R6
This section lists the issues fixed since Junos OS Release 14.2R5 for Junos Fusion.
Junos Fusion
•
On a Junos Fusion Provider Edge topology, if you configure CoS classifiers on an
aggregated Ethernet bundle comprised of satellite device extended ports, the
configuration commits and the classifiers are applied correctly. However, the output
of the show class-of-service interface ae-interface-name command does not display
the configured classifiers. As a workaround, apply the classifier on unit 0 of the LAG
and the show command output will display the correct information. PR1062500: This
issue has been resolved.
•
On a Junos Fusion Provider Edge topology, broadcast Ethernet traffic with an unknown
Ethertype might generate the following log entries: fpc0 XL[0:0]_PPE 1.xss[0] ADDR
Error and fpc0 XL[0:0]_PPE 1 Errors async xtxn error. PR1123040: This issue has been
resolved.
40
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On a Junos Fusion Provider Edge topology, if you configure Junos Fusion on an MX
Series aggregation device, corresponding system log messages might not be received
by a remote syslog server. PR1134269: This issue has been resolved.
•
On a Junos Fusion Provider Edge topology, when you insert a field-replaceable unit
(FRU) into a satellite device, the aggregation device might not generate the expected
SNMP traps for this event (such as jnxFruOnline and jnxFruInsertion). PR1136566: This
issue has been resolved.
•
On Junos Fusion Provider Edge topology configured with LACP, if a Routing Engine
switchover causes the Periodic Packet Manager (ppman) to lose connectivity with the
Periodic Packet Management Process (ppmd), and the reconnection results in new
interface entries that do not have a valid interface name, the reconnection attempt
might exceed 120 seconds and cause the LACP adjacencies to remain in the detached
state as seen in the output of the show lacp interfaces command. PR1147546: This issue
has been resolved.
•
On a Junos Fusion Provider Edge topology, if you configure the aggregation device for
the first time, satellite device to standalone device conversion might fail if the satellite
discovery and provisioning process (sdpd) has not restarted. This happens because
you perform the initial satellite management configuration on the aggregation device.
As a workaround, restart the process by issuing the restart
satellite-discovery-provisioning-process command before performing the satellite
device conversion. PR1148786: This issue has been resolved.
•
On a Junos Fusion Provider Edge topology, when you configure an integrated routing
and bridging (IRB) interface that includes both regular and extended ports, multicast
traffic might not flow to the satellite device extended ports. PR1156750: This issue has
been resolved.
•
On a Junos Fusion Provider Edge topology, you could only assign satellite all privileges
to a single user class. In Junos OS Release 14.2R6, you can now include the satellite all
statement at the [edit system login class class-name] hierarchy level for multiple classes.
PR1161531: This issue has been resolved.
Resolved Issues: Release 14.2R5
This section lists the issues fixed since Junos OS Release 14.2R4 for Junos Fusion.
Junos Fusion
•
On a Junos Fusion Provider Edge topology, if you deactivate and reactivate et-interfaces,
LACP might not come back up. As a workaround, deactivate and reactivate the
aggregated Ethernet interface that contains the et- interface. PR1078299: This issue
has been resolved.
•
On a Junos Fusion Provider Edge topology, if you issue the show interfaces media
command on an extended port, the output does not show the autonegotiation
information for the port. As a workaround, upgrade the satellite device to software
version 1.0R3 or later and the aggregation device to Junos OS Release 14.2R5 or
later.PR1078301: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
41
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On a Junos Fusion Provider Edge topology, if you issue the show interfaces diagnostics
optics satellite interface-name command for a satellite device extended port, the output
does not provide any optical transceiver diagnostic data. PR1087366: This issue has
been resolved.
•
On a Junos Fusion Provider Edge topology running bidirectional PIM, if you issue a
nonstop active routing graceful Routing Engine switchover, multicast routes are not
synchronized correctly between the master and standby Routing Engines. PR1095993:
This issue has been resolved.
•
On a Junos Fusion Provider Edge topology, if you turn off a power supply, the system
might not send an SNMP trap for this event. PR1116266: This issue has been resolved.
Resolved Issues: Release 14.2R4
This section lists the issues fixed since Junos OS Release 14.2R3 for Junos Fusion.
Junos Fusion
•
On a Junos Fusion Provider Edge topology configured for MC-LAG, if you perform an
snmpwalk on iso, the operation times out with the error message “Request failed: OID
not increasing: dot3adAggPortStatsLACPDUsRx.2387
>=dot3adAggPortStatsLACPDUsRx.2387.” PR1071050: This issue has been resolved.
•
On a Junos Fusion Provider Edge topology, if a QFX5100 switch is running Junos OS
Release 14.1X53-D16 with Enhanced Automation, and you try to convert the switch
into a satellite device by using either the automatic or manual conversion method, the
conversion might fail. PR1072806: This issue has been resolved.
•
On a Junos Fusion Provider Edge topology, if you issue any of the show chassis
commands available for satellite devices (such as show chassis hardware satellite)
and include the device-alias option to display output for a specific device, the output
might still include all the devices.PR1080516: This issue has been resolved.
Resolved Issues: Release 1.0R3
This section lists the issues fixed since satellite software release 1.0R2 for Junos Fusion.
Satellite Software
•
On a Junos Fusion Provider Edge topology, if you issue the show interfaces extensive
command on a copper-based satellite device extended port, the output does not show
autonegotiation information. As a workaround, upgrade the aggregation device to
Junos OS Release 14.2R5 or later and upgrade the satellite device to satellite software
version 1.0R3. PR1107243: This issue has been resolved.
Resolved Issues: Release 1.0R2
This section lists the issues fixed since satellite software release 1.0R2 for Junos Fusion.
42
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
Satellite Software
•
On a Junos Fusion Provider Edge topology, if you issue the show interfaces diagnostics
optics satellite interface-name command for a satellite device extended port, the
output does not provide any optic transceiver diagnostic data. PR1087366: This issue
has been resolved.
•
On a Junos Fusion Provider Edge topology, if you issue the show chassis hardware
satellite command, the output indicates that EX4300-24T satellite devices are
unsupported. As a workaround, upgrade the satellite devices to satellite software 1.0R2
and the aggregation devices to Junos OS Release 14.2R5 or later. PR1126060: This issue
has been resolved.
•
On a Junos Fusion Provider Edge topology with QFX5100 satellite devices running
satellite software version 1.0R1-S2 or earlier, if you remove a 1 gigabit small-form factor
pluggable (SFP) fiber transceiver and replace it with a copper transceiver, the port
might not transmit or receive traffic. As a workaround, restore the fiber transceiver in
the port or upgrade the satellite software to version 1.0R2 or later. PR1140313: This issue
has been resolved.
•
In a Junos Fusion Provider Edge topology, if there are power failures or the power is not
connected to a power supply on a satellite device, the jnxPowerSupplyFailure traps
are not generated by the aggregation device. For example, if there are two Power Entry
Modules (PEMs) inserted on the satellite device and one PEM is not powered on, the
aggregation device does not generate a trap for the PEM without power. PR1140097:
This issue has been resolved.
Related
Documentation
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Known Issues on page 39
•
Documentation Updates on page 43
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Documentation Updates
This section lists the errata or changes in Junos OS Release 14.2R6 for Junos Fusion
Provider Edge documentation.
Related
Documentation
•
There are no errata and changes in the current Junos Fusion Provider Edge
documentation.
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
Copyright © 2016, Juniper Networks, Inc.
43
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Migration, Upgrade, and Downgrade Instructions on page 44
•
Product Compatibility on page 57
Migration, Upgrade, and Downgrade Instructions
This section contains the procedure to upgrade Junos OS, and the upgrade and downgrade
policies for Junos OS for Junos Fusion Provider Edge. Upgrading or downgrading Junos
OS can take several hours, depending on the size and configuration of the network.
•
Basic Procedure for Upgrading an Aggregation Device on page 44
•
Upgrading an Aggregation Device with Redundant Routing Engines on page 46
•
Preparing the Switch for Satellite Device Conversion on page 47
•
Autoconverting a Switch into a Satellite Device on page 48
•
Manually Converting a Switch into a Satellite Device on page 50
•
Configuring a Switch into a Satellite Device Before Connecting It to a Junos Fusion
Topology on page 52
•
Configuring Satellite Device Upgrade Groups on page 53
•
Converting a Satellite Device to a Standalone Device on page 54
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 56
•
Downgrading from Release 14.2 on page 57
Basic Procedure for Upgrading an Aggregation Device
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: 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:
[email protected]> 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. See the Junos OS Administration Library for
Routing Devices.
44
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
The download and installation process for Junos OS Release 14.2R4. is different from
previous Junos OS releases.
1.
Using a Web browser, navigate to the Download Software URL on the Juniper Networks
webpage:
http://www.juniper.net/support/downloads/
2. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
3. Select By Technology > Junos Platform > Junos Fusion to find the software that you
want to download.
4. Select the release number (the number of the software version that you want to
download) from the Version drop-down list to the right of the page.
5. Select the Software tab.
6. Select the software package for the release.
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 aggregation device.
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 commands.
•
For 64-bit software:
NOTE: We highly recommend using 64-bit Junos OS software when
implementing Junos Fusion.
[email protected]> request system software add validate reboot
source/jinstall64-14.2R4.9-domestic-signed.tgz
•
For 32-bit software:
[email protected]> request system software add validate reboot
source/jinstall-14.2R4.9-domestic-signed.tgz
All other customers, use the following commands.
•
For 64-bit software:
NOTE: We highly recommend using 64-bit Junos OS software when
implementing Junos Fusion.
Copyright © 2016, Juniper Networks, Inc.
45
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[email protected]> request system software add validate reboot
source/jinstall64-14.2R4.9-export-signed.tgz
•
For 32-bit software:
[email protected]> request system software add validate reboot
source/jinstall-14.2R4.9-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.
•
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.2R4. 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.
Upgrading an Aggregation Device with Redundant Routing Engines
If the aggregation device has two Routing Engines, perform a Junos OS installation on
each Routing Engine separately to minimize disrupting network operations 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.
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.
46
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
For the detailed procedure, see the Installation and Upgrade Guide.
Preparing the Switch for Satellite Device Conversion
Satellite devices in a Junos Fusion topology use a satellite software package that is
different from the standard Junos OS software package. Before you can install the satellite
software package on a satellite device, you first need to upgrade the target satellite
device to an interim Junos OS software version that can be converted to satellite software.
Table 2 on page 47 shows a support matrix that maps Junos OS software used in
aggregation devices to the compatible preconverted switch software and satellite device
software.
Table 2: Aggregation Device Junos OS Software Compatibility with Satellite Software
Aggregation Device Version
Switch Version (preconversion)
Satellite Device Software Version
Junos OS Release 14.2R3
Junos OS Release 14.1X53-D16 or later
1.0R1
Junos OS Release 14.2R4
Junos OS Release 14.1X53-D25 or later
1.0R1-S2
Junos OS Release 14.2R5
Junos OS Release 14.1X53-D30 or later
1.0R2
Junos OS Release 14.2R6
Junos OS Release 14.1X53-D30 or later
1.0R3
Customers with EX4300 switches, use the following command:
[email protected]> request system software add validate reboot
source/jinstall-ex-4300-14.1X53-D30.3-domestic-signed.tgz
Customers with QFX5100 switches, use the following command:
[email protected]> request system software add validate reboot
source/jinstall-qfx-5-14.1X53-D30.3-domestic-signed.tgz
When the interim installation has completed and the switch is running a version of Junos
OS that is compatible with satellite device conversion, perform the following steps:
1.
Log in to the device using the console port.
2. Clear the device:
[edit]
[email protected]# request system zeroize
NOTE: The device reboots to complete the procedure for resetting the
device.
If you are not logged in to the device using the console port connection, your connection
to the device is lost after entering the request system zeroize command.
If you lose your connection to the device, log in using the console port.
3. (EX4300 switches only) After the reboot is complete, convert the built-in 40-Gbps
QSFP+ interfaces from Virtual Chassis ports (VCPs) into network ports:
[email protected]> request virtual-chassis vc-port delete pic-slot 1 port port-number
Copyright © 2016, Juniper Networks, Inc.
47
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
For example, to convert all four built-in 40-Gbps QSFP+ interfaces on an EX4300-24P
switch into network ports:
[email protected]>request virtual-chassis vc-port delete pic-slot 1 port 0
[email protected]> request virtual-chassis vc-port delete pic-slot 1 port 1
[email protected]> request virtual-chassis vc-port delete pic-slot 1 port 2
[email protected]> request virtual-chassis vc-port delete pic-slot 1 port 3
This step is required for the 40-Gbps QSFP+ interfaces that will be used as uplink
interfaces in a Junos Fusion topology. Built-in 40-Gbps QSFP+ interfaces on EX4300
switches are configured into VCPs by default, and the default settings are restored
after the device is reset.
After this initial preparation, you can use one of three methods to convert your switches
into satellite devices—autoconversion, manual conversion, and preconfiguration.
Autoconverting a Switch into a Satellite Device
Use this procedure to automatically configure a switch into a satellite device when it is
cabled into the aggregation device.
You can use the autoconversion procedure to add one or more satellite devices to your
Junos Fusion topology. The autoconversion procedure is especially useful when you are
adding multiple satellite devices to Junos Fusion, because it allows you to easily configure
the entire topology before or after cabling the satellite devices to the aggregation devices.
Before you begin:
•
Ensure that your aggregation device is running Junos OS Release 14.2R5 or later, and
that the satellite devices are running Junos OS Release 14.1X53-D30 or later.
To autoconvert a switch into a satellite device:
1.
Cable a link between the aggregation device and the satellite device, if desired.
NOTE: You can cable the aggregation device to the satellite device at any
point in this procedure.
When the aggregation device is cabled to the satellite device during this
procedure, the process for converting a switch into a satellite device to
finalize this process occurs immediately.
If the aggregation device is not cabled to the satellite device, the process
for converting a switch into a satellite device to finalize this process starts
when the satellite device is cabled to the aggregation device.
2. Log in to the aggregation device.
3. Configure the cascade ports.
For example, to configure interface xe-0/0/1 on the aggregation device into a cascade
port:
[edit]
[email protected]# set interfaces xe-0/0/1 cascade-port
48
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
4. Associate an FPC slot ID with each satellite device.
Examples:
•
To configure the FPC slot ID of the satellite device that is connected to xe-0/0/1 to
101:
[edit]
[email protected]# set chassis satellite-management fpc 101 cascade-ports
xe-0/0/1
•
To map FPC slot ID 101 to the satellite device using the serial number ABCDEFGHIJKL:
[edit]
[email protected]# set chassis satellite-management fpc 101 serial-number
ABCDEFGHIJKL
•
To map FPC slot ID to the satellite device using MAC address 12:34:56:AB:CD:EF:
[edit]
[email protected]# set chassis satellite-management fpc 110 system-id
12:34:56:AB:CD:EF
5. (Recommended) Configure an alias name for the satellite device:
[edit]
[email protected]# set chassis satellite-management fpc slot-id alias alias-name
where slot-id is the FPC slot ID of the satellite device defined in the previous step, and
alias-name is the alias.
For example, to configure the satellite device numbered 101 as qfx5100-48s-1:
[edit]
[email protected]# set chassis satellite-management fpc 101 alias qfx5100-48s-1
6. Configure an FPC slot ID into a software upgrade group.
For example, to add a satellite device with FPC number 101 to an existing software
group named group1, or create a software upgrade group named group1 and add a
satellite device with FPC slot 101 to the group:
[edit]
[email protected]# set chassis satellite-management upgrade-group group1 satellite
101
If you are creating a new software upgrade group in this step, you also need to associate
the group with a satellite software image. You can skip this final step if the software
upgrade group has been created and an association already exists.
Before associating a satellite software image with a satellite software group, the
configuration with the satellite software upgrade group must be committed:
[edit]
[email protected]# commit synchronize
After committing the configuration, associate a satellite software image named
satellite-1.0R3-signed.tgz to the upgrade group named group1:
[email protected]> request system software add /var/tmp/satellite-1.0R3-signed.tgz
upgrade-group group1
7. Enable automatic satellite conversion:
[edit]
[email protected]# set chassis satellite-management auto-satellite-conversion
satellite slot-id
Copyright © 2016, Juniper Networks, Inc.
49
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
For example, to automatically convert FPC 101 into a satellite device:
[edit]
[email protected]# set chassis satellite-management auto-satellite-conversion
satellite 101
8. Commit the configuration:
[edit]
[email protected]# commit
If you want to commit the configuration to both Routing Engines:
[edit]
[email protected]# commit synchronize
The satellite software upgrade on the satellite device begins after this final step is
completed, or after you cable the satellite device to a cascade port using automatic
satellite conversion if you have not already cabled the satellite device to the
aggregation device.
After the satellite software update, the switch operates as a satellite device in the
Junos Fusion topology
Manually Converting a Switch into a Satellite Device
Use this procedure to manually convert a switch into a satellite device after cabling it
into the Junos Fusion topology.
This procedure should be used to convert a switch that is not currently acting as a satellite
device into a satellite device. A switch might not be recognized as a satellite device for
several reasons, including that the device was not previously autoconverted into a satellite
device or that the switch had previously been reverted from a satellite device to a
standalone switch.
Before you begin:
•
Ensure that your aggregation device is running Junos OS Release 14.2R5 or later, and
that the switches that will become satellite devices are running Junos OS Release
14.1X53-D30 or later.
To manually convert a switch into a satellite device:
1.
Cable a link between the aggregation device and the satellite device.
2. Log in to the aggregation device.
3. Configure the link on the aggregation device into a cascade port, if you have not done
so already.
For example, to configure interface xe-0/0/1 on the aggregation device into a cascade
port:
[edit]
[email protected]# set interfaces xe-0/0/1 cascade-port
4. Associate an FPC slot ID with the satellite device.
Examples:
50
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
•
To configure the FPC slot ID of the satellite device that is connected to xe-0/0/1 to
101:
[edit]
[email protected]# set chassis satellite-management fpc 101 cascade-ports
xe-0/0/1
•
To map FPC slot ID 101 to the satellite device using the serial number ABCDEFGHIJKL:
[edit]
[email protected]# set chassis satellite-management fpc 101 serial-number
ABCDEFGHIJKL
•
To map FPC slot ID to the satellite device using MAC address 12:34:56:AB:CD:EF:
[edit]
[email protected]# set chassis satellite-management fpc 110 system-id
12:34:56:AB:CD:EF
5. Configure the interface on the aggregation device into a software upgrade group.
For example, to add a satellite device with FPC number 101 to an existing software
group named group1, or create a software upgrade group named group1 and add a
satellite device configured with FPC number 101 to the group:
[edit]
[email protected]# set chassis satellite-management upgrade-group group1 satellite
101
If you are creating a new software upgrade group in this step, you also need to associate
the group with a satellite software image. You can skip this final step if the software
upgrade group has been created and an association already exists.
Before associating a satellite software image with a satellite software group, the
configuration with the satellite software upgrade group must be committed:
[edit]
[email protected]# commit synchronize
After committing the configuration, associate a satellite software image named
satellite-1.0R3-signed.tgz to the upgrade group named group1:
[email protected]> request system software add /var/tmp/satellite-1.0R3-signed.tgz
upgrade-group group1
6. Commit the configuration:
[edit]
[email protected]# commit
If you want to commit the configuration to both Routing Engines:
[edit]
[email protected]# commit synchronize
7. Manually configure the switch into a satellite device:
[email protected]> request chassis satellite interface interface-name device-mode
satellite
For example, to manually configure the switch that is connecting the satellite device
to interface xe-0/0/1 on the aggregation device into a satellite device:
[email protected]> request chassis satellite interface xe-0/0/1 device-mode satellite
The satellite software upgrade on the satellite device begins after this final step is
completed.
Copyright © 2016, Juniper Networks, Inc.
51
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
After the satellite software update, the switch operates as a satellite device in the
Junos Fusion topology
Configuring a Switch into a Satellite Device Before Connecting It to a Junos Fusion
Topology
Use this procedure to install the satellite software onto a switch before interconnecting
it into a Junos Fusion topology as a satellite device. Installing the satellite software on a
switch before interconnecting it to a Junos Fusion topology allows you to more
immediately deploy the switch as a satellite device by avoiding the downtime associated
with the satellite software installation procedure for Junos Fusion.
Before you begin:
•
Ensure that your switch that will become a satellite device is running Junos OS Release
14.1X53-D30 or later.
•
Ensure that you have copied the satellite software onto the device that will become
a satellite device.
NOTE: Ensure there is sufficient space available in the /var/tmp directory
to be able to copy the software to the switch (especially for EX4300
switches). If there is not enough memory available, issue the request system
storage cleanup command on the device before attempting to perform the
conversion.
In SNOS Release 1.0R3, a satellite-ppc-1.0R3.2-signed.tgz package is
included specifically for converting Junos OS to satellite on EX4300 to
address a EX4300 switch space issue. The satellite-ppc package is to be
used only for configuring a switch into a satellite device before connecting
it to a Junos Fusion topology.
1.
You can manually install the satellite software onto a switch by entering the following
command:
[email protected]> request chassis device-mode satellite URL-to-satellite-software
For instance, to install the satellite software package satellite-1.0R3.2-signed.tgz
stored in the /var/tmp/ directory on the switch:
[email protected]> request chassis device-mode satellite
/var/tmp/satellite-1.0R3.2-signed.tgz
•
To install satellite software onto a QFX5100 switch, use the
satellite-1.0R3.2-signed.tgz satellite software package.
•
To install satellite software onto a EX4300 switch, use the
satellite-ppc-1.0R3.2-signed.tgz satellite software package.
2. The device will reboot to complete the satellite software installation.
52
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
After the satellite software is installed, follow this procedure to connect the switch into
a Junos Fusion topology:
1.
Log in to the aggregation device.
2. Configure the link on the aggregation device into a cascade port, if you have not done
so already.
For example, to configure interface xe-0/0/1 on the aggregation device into a cascade
port:
[edit]
[email protected]# set interfaces xe-0/0/1 cascade-port
3. Configure the satellite switch into a satellite software upgrade group that is using the
same version of satellite software that was manually installed onto the switch.
This step is advisable, but not always required. Completing this step ensures that the
satellite software on your device is upgraded to the version of satellite software
associated with the satellite software upgrade group when the satellite device
connects to the aggregation device.
4. Commit the configuration.
To commit the configuration to both Routing Engines:
[edit]
[email protected]# commit synchronize
To commit the configuration to a single Routing Engine:
[edit]
[email protected]# commit
5. Cable a link between the aggregation device and the satellite device.
Configuring Satellite Device Upgrade Groups
To simplify the upgrade process for multiple satellite devices, you can create a software
upgrade group at the aggregation device, assign satellite devices to the group, and install
the satellite software on a groupwide basis.
To create a software upgrade group and assign satellite devices to the group, include
the satellite statement at the [edit chassis satellite-management upgrade-groups
upgrade-group-name] hierarchy level.
To configure a software upgrade group and assign satellite devices to the group:
1.
Log in to the aggregation device.
2. Create the software upgrade group, and add the satellite devices to the group.
[edit]
[email protected]# set chassis satellite-management upgrade-groups
upgrade-group-name satellite satellite-member-number-or-range
upgrade-group-name is the name of the upgrade group, and the
satellite-member-number-or-range is the member numbers of the satellite devices that
are being added to the upgrade group. If you enter an existing upgrade group name as
Copyright © 2016, Juniper Networks, Inc.
53
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
the upgrade-group-name, you add new satellite devices to the existing software upgrade
group.
For example, to create a software upgrade group named group1 that includes all satellite
devices numbered 101 through 120, configure the following:
[edit]
[email protected]# set chassis satellite-management upgrade-groups group1 satellite
101-120
To install, remove, or roll back a satellite software version on an upgrade group, issue
the following operational mode commands:
•
request system software add upgrade-group group-name—Install the satellite software
on all members of the specified upgrade group.
•
request system software delete upgrade-group group-name—Remove the satellite
software association from the specified upgrade group.
•
request system software rollback upgrade-group group-name—Associate an upgrade
group with a previous version of satellite software.
Customers installing satellite software on EX4300 and QFX5100 switches referenced
in a software upgrade group, use the following command:
[email protected]> request system software add upgrade-group group-name
source/satellite-1.0R3.2-signed.tgz
A copy of the satellite software is saved on the aggregation device. When you add a
satellite device to an upgrade group that is not running the same satellite software version,
the new satellite device is automatically updated to the version of satellite software that
is associated with the upgrade group.
You can issue the show chassis satellite software command to see which software images
are stored on the aggregation device and which upgrade groups are associated with the
software images.
Converting a Satellite Device to a Standalone Device
In the event that you need to convert a satellite device to a standalone device, you will
need to install a new Junos OS software package on the satellite device and remove it
from the Junos Fusion topology.
NOTE: If the satellite device is a QFX5100 switch, you need to install a PXE
version of Junos OS. The PXE version of Junos OS is the software that includes
pxe in the Junos OS package name when it is downloaded from the Software
Center—for example, the PXE image for Junos OS Release 14.1X53-D30 is
named install-media-pxe-qfx-5-14.1X53-D30.3.tgz. If the satellite device is
an EX4300 switch, you install a standard jinstall-ex-4300 version of Junos
OS.
54
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
The following steps explain how to download software, remove the satellite device from
Junos Fusion, and install the Junos OS software image on the satellite device so that the
device can operate as a standalone device.
1.
Using a Web browser, navigate to the Junos OS software download URL on the Juniper
Networks webpage:
http://www.juniper.net/support/downloads
2. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
3. Select By Technology > Junos Platform > Junos Fusion from the drop-down list and
select the switch platform series and model for your satellite device.
4. Select the Junos OS Release 14.1X53-D30 software image for your platform.
5. Review and accept the End User License Agreement.
6. Download the software to a local host.
7. Copy the software to the routing platform or to your internal software distribution
site.
8. Remove the satellite device from the automatic satellite conversion configuration.
If automatic satellite conversion is enabled for the satellite device’s member number,
remove the member number from the automatic satellite conversion configuration.
The satellite device’s member number is the same as the FPC slot ID. You can check
the automatic satellite conversion configuration by entering the show command at
the [edit chassis satellite-management auto-satellite-conversion] hierarchy level.
[edit]
[email protected]# delete chassis satellite-management auto-satellite-conversion
satellite member-number
For example, to remove member number 101 from Junos Fusion:
[edit]
[email protected]# delete chassis satellite-management auto-satellite-conversion
satellite 101
9. Commit the configuration.
To commit the configuration to both Routing Engines:
[edit]
[email protected]# commit synchronize
Otherwise, commit the configuration to a single Routing Engine:
[edit]
[email protected]# commit
10. Install the Junos OS software on the satellite device to convert the device to a
standalone device.
[edit]
[email protected]> request chassis satellite install URL-to-software-package fpc-slot
member-number
For example, to install a PXE software package stored in the /var/tmp directory on
the aggregation device onto a QFX5100 switch acting as the satellite device using
FPC slot 101:
Copyright © 2016, Juniper Networks, Inc.
55
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[edit]
[email protected]> request chassis satellite install
/var/tmp/install-media-pxe-qfx-5-14.1X53-D30.3.tgz fpc-slot 101
For example, to install a software package stored in the var/tmp directory on the
aggregation device onto an EX4300 switch acting as the satellite device using FPC
slot 101:
[edit]
[email protected]> request chassis satellite install
/var/tmp/jinstall-ex-4300-14.1X53-D30.3-domestic-signed.tgz fpc-slot 101
The satellite device stops participating in the Junos Fusion topology once the software
installation starts. The software upgrade starts after this command is entered.
11. Wait for the reboot that accompanies the software installation to complete.
12. When you are prompted to log back into your device, uncable the device from the
Junos Fusion topology. See Removing a Transceiver from a QFX Series Device or
Removing a Transceiver from a Switch, as needed. Your device has been removed from
Junos Fusion.
NOTE: The device uses a factory default configuration after the Junos OS
installation is complete.
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
56
Copyright © 2016, Juniper Networks, Inc.
Product Compatibility
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.
Related
Documentation
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
•
Product Compatibility on page 57
Product Compatibility
•
Hardware Compatibility on page 57
Hardware Compatibility
To obtain information about the components that are supported on the devices, and
special compatibility guidelines with the release, see the Hardware Guides for the devices
used in your Junos Fusion Provider Edge topology.
To determine the features supported on Junos Fusion devices, 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
•
New and Changed Features on page 28
•
Changes in Behavior and Syntax on page 37
•
Known Behavior on page 38
•
Known Issues on page 39
•
Resolved Issues on page 40
•
Documentation Updates on page 43
Copyright © 2016, Juniper Networks, Inc.
57
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
58
Migration, Upgrade, and Downgrade Instructions on page 44
Copyright © 2016, Juniper Networks, Inc.
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.2R6 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.
You can also find these release notes on the Juniper Networks Junos OS Documentation
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 recommend that you not use unified ISSU to upgrade
from an earlier Junos OS release to Junos OS Release 14.2.
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Resolved Issues on page 118
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R6 for the M Series, MX Series, and T Series.
•
Hardware on page 60
•
Authentication, Authorization and Accounting (AAA) (RADIUS) on page 61
•
Class of Service (CoS) on page 61
•
General Routing on page 62
•
High Availability (HA) and Resiliency on page 62
•
Interfaces and Chassis on page 64
•
IPv4 on page 74
•
IPv6 on page 74
•
Junos Fusion on page 74
•
Layer 2 Features on page 74
•
Layer 2 VPN on page 76
•
Management on page 76
•
MPLS on page 76
Copyright © 2016, Juniper Networks, Inc.
59
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Multicast on page 78
•
Network Management and Monitoring on page 79
•
Operation, Administration, and Maintenance (OAM) on page 81
•
Routing Policy and Firewall Filters on page 83
•
Routing Protocols on page 85
•
Services Applications on page 86
•
Software-Defined Networking (SDN) on page 89
•
Subscriber Management and Services on page 90
•
System Management on page 93
•
User Interface and Configuration on page 93
•
VPNs on page 93
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.
60
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
[See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications, MX Series Interface
Module Reference, and wavelength.]
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)—Starting with 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.
Copyright © 2016, Juniper Networks, Inc.
61
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
•
Support for packet marking schemes on a per-customer basis (MX
Series)—Traditionally, packet marking in Junos OS uses the forwarding class and loss
priority determined from a BA classifier or multifield classifier. This approach does not
allow for direct assignment of rewrite rules on a per-customer basis due to the limited
number of combinations of forwarding class and loss priority.
Beginning with Junos OS Release 14.2R3, there is a packet marking scheme, called
policy map, that allows the definition of rewrite rules on a per-customer basis. Policy
maps are defined at the [edit class-of-service policy-map] hierarchy level and can be
assigned to a customer through a firewall action, an ingress interface, or a routing
policy.
General Routing
•
Configurable TCP MSS value (MX Series)—Starting in Junos OS Release 14.2, you can
configure the TCP MSS value on MX Series routers. To specify a TCP MSS value, 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
•
62
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.
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.]
•
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 MS-MPC on SCBE2 (MX Series)—Starting with Junos OS Release 14.2R2,
MS-MPC is supported on SCBE2 on MX240, MX480, and MX960 routers.
•
MX Series Virtual Chassis support for MX2010 and MX2020 member routers (MX
Series with MPCs/MICs)—Starting in Junos OS Release 14.2R2, you can configure an
MX2010 router or MX2020 router as a member router in an MX Series Virtual Chassis.
In earlier releases, MX2010 routers and MX2020 routers cannot function as member
routers in an MX Series Virtual Chassis.
In a two-member Virtual Chassis configuration, the following member router
combinations are supported with an MX2010 router or MX2020 router:
•
MX960 router and MX2010 router
•
MX960 router and MX2020 router
•
MX2010 router and MX2020 router
•
MX2010 router and MX2010 router
•
MX2020 router and MX2020 router
Copyright © 2016, Juniper Networks, Inc.
63
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
To ensure that a Virtual Chassis configuration consisting of an MX2020 router and
either an MX960 router or MX2010 router forms properly, you must issue the request
virtual-chassis member-id set member member-id slots-per-chassis slot-count command,
where member-id is the member ID (0 or 1) configured for the MX960 router or MX2010
router, and slot-count is 20 to match the slot count for the MX2020 router. In addition,
for a Virtual Chassis that includes an MX2020 member router, all four Routing Engines
in the Virtual Chassis configuration must have at least 16 gigabytes of memory.
•
Enhancements made to unified ISSU for VRRPv3 to avoid adjacency flap (M Series
and MX Series)—Starting in Junos OS Release 14.2R2, enhancements have been made
to maintain protocol adjacency with peer routers during unified ISSU and to maintain
interoperability among equipment and with other Junos OS releases and other Juniper
Networks products. This design is for VRRPv3 only. VRRPv1 and VRRPv2 are not
supported. The show vrrp command output is updated to display unified ISSU
information.
Interfaces and Chassis
•
•
Unified in-service software upgrade support—Starting with Junos OS Release 14.2,
unified in-service software upgrade (unified ISSU) is supported on the following MICs:
•
Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP
•
Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP
•
Channelized E1/T1 Circuit Emulation MIC
•
DS3/E3 MIC
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
64
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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
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 VLAN trunk 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. You 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).
•
Port-based network access control (MX240, MX480, and MX960)—Starting in Junos
OS Release 14.2, support is implemented for controlling access to your network through
Copyright © 2016, Juniper Networks, Inc.
65
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
•
66
Support for MACsec (MX Series)—Starting in Junos OS Release 14.2R2, you can
configure Media Access Control Security (MACsec) on MX Series routers with the
enhanced 20-port Gigabit Ethernet MIC (model number MIC-3D-20GE-SFP-E). MACsec
is an industry-standard security technology that provides secure communication for
almost all types of traffic on Ethernet links. You can enable MACsec using static
connectivity association key (CAK) security mode or static secure association key
(SAK) security mode by using the connectivity-association connectivity-association-name
statement and its substatements at the [edit security macsec] hierarchy level. MACsec
is supported on MX Series routers in both enhanced LAN mode (by entering the
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
network-services lan statement at the [edit chassis] hierarchy level) and in
non-enhanced LAN mode.
MACsec using static secure association key (SAK) security mode does not work properly
on MX80 routers and FPC slots other than slot 0 of MX104 routers. MACsec is not
supported with unified ISSU. After a unified ISSU operation is completed, an FPC reboot
is required for MACSec to work. If you upgrade a router from an earlier Junos OS release
to Release 14.2R2 using unified ISSU and MACsec is configured on that router, you must
reboot the FPC for MACsec to function properly.
•
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
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 and element ID 64, 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)–Staring with Release 14.2, 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
Copyright © 2016, Juniper Networks, Inc.
67
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
•
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.]
•
68
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
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
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)—Starting in Junos OS Release 14.2, 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.]
•
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)—Starting with Release 14.2, Junos OS 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.
Copyright © 2016, Juniper Networks, Inc.
69
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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, starting with Junos OS Release 14.2, 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.]
•
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.
70
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
Enhanced Y.1731 functionality on VPWS to support ETH-LM for dual VLAN tags (MX
Series)—Starting with Release 14.2, 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 5 seconds or more, with
an up and down duration of 1 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.]
•
Support for NAT port block allocation (MX Series routers with
MS-MPCs/MS-MICs)—Starting in Junos OS Release 14.2R2, you can configure port
block allocation for NAT with port translation (NAPT) on MX Series routers with
MS-MPCs or MS-MICs. You can use the existing CLI and configuration procedures used
for other interface cards. Deterministic port block allocation is not supported.
[See Configuring Address Pools for Network Address Port Translation (NAPT) Overview
and secured-port-block-allocation.]
•
Provide egress VLAN ID and direction information in sampling records (MX
Series)—Starting in Release 14.2R2 , Junos OS includes egress VLAN ID and flow
direction information in output records and, optionally, flow keys, when you perform
sampling using the IPFIX or version 9 templates.
•
VLAN ID used for single-tagging is output to field 58, Vlan Id.
•
VLAN IDs used for dual-tagging (QinQ) are output to fields 243, Dot1q Vlan Id, and
245, Dot1q Customer Vlan Id. (IPFIX template only)
•
To put one or two Vlan IDs in the flow key of the output record, include the vlan-id
option at the [edit services flow-monitoring version-ipfix template template-name
flow-key] or [edit services flow-monitoring version9 template template-name flow-key]
hierarchy level.
•
To put flow direction in the flow key of the output record, include the flow-direction
option at the [edit services flow-monitoring version-ipfix template template-name
Copyright © 2016, Juniper Networks, Inc.
71
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
flow-key] or [edit services flow-monitoring version9 template template-name flow-key]
hierarchy level.
•
The flow direction field in the output record contains an initial value of 0xFF. The
field contains 0x00 (ingress) or 0x01 (egress) only when you include the
flow-direction vlan-id option at the [edit services flow-monitoring version-ipfix template
template-name flow-key] or [edit services flow-monitoring version9 template
template-name flow-key] hierarchy level.
NOTE: In Junos OS releases earlier than Release 14.2R2, only ingress VLAN
IDs were reported in flow records.
[See Configuring Flow Aggregation to Use IPFIX Flow Templates and Configuring Flow
Aggregation to Use Version 9 Flow Templates.]
•
Support for ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on aggregated Ethernet
interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 14.2R3, you
can configure ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM),
Ethernet synthetic loss measurement (ETH-SLM), and Ethernet delay measurement
(ETH-DM) capabilities on aggregated Ethernet (ae) interfaces. These performance
monitoring functionalities are supported on MX Series routers with MPCs, where the
same level of support for the Ethernet services OAM mechanisms as the level of support
on non-aggregated Ethernet interfaces is available on aggregated Ethernet interfaces.
ETH-DM is supported on MPC3E and MPC4E modules with only software timestamping.
ETH-SLM is supported on MPC3E and MPC4E modules.
•
Configuration support to improve MC-LAG Layer 2 and Layer 3 convergence (MX
Series)—Starting with Junos OS Release 14.2R3, you can configure multichassis link
aggregation (MC-LAG) interfaces to improve Layer 2 and Layer 3 convergence time to
subsecond values when a multichassis aggregated Ethernet link goes down or comes
up in a bridge domain.
To use this feature, ensure that the interchassis link (ICL) is configured on an aggregated
Ethernet interface. For Layer 2 convergence, configure the enhanced-convergence
statement at the [edit interfaces aeX aggregated-ether-options mc-ae] hierarchy level.
For Layer 3, configure the enhanced-convergence statement at the [edit interfaces irb
unit unit-number] hierarchy level for an integrated routing and bridging (IRB) interface.
72
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
NOTE:
• If the enhanced-convergence feature is configured on a multichassis
aggregated Ethernet interface of a bridge domain that has an IRB
interface, the IRB interface must also be configured for the convergence
feature.
•
All multichassis aggregated Ethernet interfaces that are part of a bridge
domain must be configured for enhanced convergence in order to utilize
this feature on any of them.
•
On enabling or disabling the enhanced convergence feature, all services
get deleted and re-created.
[See Configuring Active-Active Bridging and VRRP over IRB in Multichassis Link Aggregation
on MX Series Routers.]
•
LACP hold-up timer configuration support on LAG interfaces—Starting with Junos
OS Release 14.2R3, you can configure a Link Aggregation Control Protocol (LACP)
hold-up timer value for link aggregation group (LAG) interfaces.
You configure the hold-up timer to prevent excessive flapping of a child (member) link
of a LAG interface due to transport layer issues. With transport layer issues, it is possible
for a link to be physically up and still cause an LACP state-machine flap. An LACP
state-machine flapping can adversely affect traffic on the LAG interface. To prevent
this, a hold-up timer value is configured. LACP monitors the PDUs received on the child
link for the configured time value, but does not allow the member link to transition
from the expired or defaulted state to current state. This configuration thus prevents
excessive flapping of the member link.
To configure the LACP hold-up timer for LAG interfaces, use the hold-time up timer-value
statement at the [edit interfaces ae aeX aggregated-ether-options lacp] hierarchy level.
Copyright © 2016, Juniper Networks, Inc.
73
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
IPv4
•
IPv4 address conservation method for hosting providers (MX Series)—Starting in
Junos OS Release 14.2R4, you can configure a static route on an IRB interface with or
without pinning to a specific underlying interface, thereby conserving the usage of IP
address space.
When a customer needs servers to be assigned within a block of IP addresses, several
IP addresses are consumed. These include the network and broadcast IP addresses,
the addresses for the router gateway that the servers are connected to, and the
addresses of the individual servers. When this effect is multiplied across thousands of
hosting providers, IP address space is far from being used efficiently.
This issue can be resolved by configuring the interface on the router with an address
from the reserved IPv4 prefix for shared address space (RFC 6598) and by using static
routes pointed at the interface. IANA has recorded the allocation of an IPv4 /10 for use
as shared address space. The shared address space address range is 100.64.0.0/10.
This way, the interface in the router is allocated an IP address from the shared address
space, so it is not consuming publicly routable address space, and connectivity is
handled with static routes on an interface. The interface in the server is configured with
a publicly routable address, but the router interfaces are not. Network and broadcast
addresses are consumed out of the shared address space rather than the publicly
routable address space.
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.]
Junos Fusion
•
Junos Fusion (MX Series)—Starting with Release 14.2, Junos Fusion is supported on
MX Series routers. For Junos Fusion related information, see “New and Changed
Features” on page 28 for Junos Fusion.
Layer 2 Features
•
74
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:
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
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 vc-id-number].
[See the vpls-id-list command reference.]
•
Native analyzer support (MX240, MX480 and MX960)—Starting with Junos OS
Release 14.2, MX Series routers support 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.
Copyright © 2016, Juniper Networks, Inc.
75
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Layer 2 VPN
•
Control word feature for LDP VPLS and FEC129 VPLS (MX Series)— Starting with
Junos OS Release 14.2R4, the control word feature is supported for LDP VPLS and
FEC129 VPLS.
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.
[See Understanding YANG on Devices Running Junos OS.]
MPLS
•
On-demand packet loss and delay measurement (MX Series routers with MPCs and
MICs only)—Starting with Release 14.2, Junos OS 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.]
76
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
Extension of traceroute over MPLS tunnels—Starting with Junos OS Release 14.2, 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:
•
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.]
•
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.]
•
Egress peer engineering of service labels (BGP, MPLS) and egress peer protection
for BGP-LU (MX Series)—Beginning with Junos OS Release 14.2R4, you can enable
traffic engineering of service traffic, such as MPLS LSP traffic between autonomous
systems (ASs), using BGP-labeled unicast for optimum utilization of the advertised
egress routes. You can specify one or more backup devices for the primary egress AS
boundary router. Junos OS installs the backup path in addition to the primary path in
the MPLS forwarding table, which enables MPLS fast reroute (FRR) when the primary
link fails.
•
Support of Internet draft draft-ietf-pce-stateful-pce-07 for the stateful PCC
implementation (M Series, MX Series, and T Series)—The partial client-side
implementation of the stateful Path Computation Element (PCE) architecture is
currently based on version 2 of Internet draft draft-ietf-pce-stateful-pce. Starting with
Junos OS Release 14.2R4, this implementation is upgraded to support version 7, as
defined in Internet draft draft-ietf-pce-stateful-pce-07.
Releases earlier than 14.2R4 support the older version of the PCE draft, causing
interoperability issues between a Path Computation Client (PCC) running a previous
Copyright © 2016, Juniper Networks, Inc.
77
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
release and a stateful PCE server that adheres to Internet draft
draft-ietf-pce-stateful-pce-07.
•
Support of Internet draft draft-crabbe-pce-pce-initiated-lsp-03 for the stateful
PCE-initiated LSP implementation (M Series, MX Series, and T Series)—In the partial
client-side implementation of the stateful Path Computation Element (PCE)
architecture, the implementation of PCE-controlled LSPs that are dynamically initiated
by a PCE is currently based on version 1 of Internet draft
draft-crabbe-pce-pce-initiated-lsp. Starting with Junos OS Release 14.2R4, this
implementation is upgraded to support version 3, as defined in Internet draft
draft-crabbe-pce-pce-initiated-lsp-03.
Releases prior to 14.2R4 support the older version of the PCE draft, causing
interoperability issues between a Path Computation Client (PCC) running a previous
release and a stateful PCE server that adheres to Internet draft
draft-crabbe-pce-pce-initiated-lsp-03.
Multicast
•
BGP link state distribution (M Series, MX Series, and T Series)—Starting with Release
14.2, Junos OS 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.]
•
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 (MX Series
routers with MPCs and DPCs)—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 MPCs and DPCs. 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
78
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.
Network Management and Monitoring
•
Configuring SNMP to match jnxNatObjects values for MS-DPC and MS-MIC (MX
Series)—In Junos OS Release 13.3R7, 14.1R6, and 14.2R4, you can configure the
snmp-value-match-msmic statement at the [edit services service-set service-set-name
nat-options] hierarchy level.
In networks where both MS-DPC and MS-MIC are deployed, you can configure this
statement to ensure that the values for MS-MIC-specific objects in the jnxNatObjects
MIB table match the values for MS-DPC objects. By default, this feature is disabled.
You can use the deactivate services service-set service-set-name nat-options
snmp-value-match-msmic configuration mode command to disable this feature.
•
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.
[See show snmp stats-response-time and show snmp statistics.]
•
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.
[See Juniper Networks Enterprise-Specific MIBs and Supported Devices, Juniper Networks
Enterprise-Specific MIBs, and SNMP MIBs and Traps Reference.]
Copyright © 2016, Juniper Networks, Inc.
79
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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.
[See commit (system) and delta-export.]
•
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.
•
SNMP support for fabric queue depth, WAN queue depth, and fabric counter (MX240,
MX480, MX960, MX2010, and MX2020)—Starting with Release 14.2R3, Junos OS
provides SNMP support for WAN queue depth, fabric queue depth, and fabric counter.
The following SNMP MIB tables include the associated objects:
•
jnxCosQstatTable table
•
jnxCosIngressQstatTable table
•
jnxFabricMib table
In addition, this feature supports the following traps for the Packet Forwarding Engine
resource monitoring MIBs:
•
80
jnxPfeMemoryTrapVars
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
jnxPfeMemoryNotifications
[See jnxCosQstatTable, jnxCosIngressQstatTable, jnxFabricMib, jnxPfeMemoryTrapVars,
and jnxPfeMemoryNotificationsPrefix.]
Operation, Administration, and Maintenance (OAM)
•
Support for MEF-36-compliant performance monitoring (MX Series)—Starting in
Release 14.2R5, Junos OS supports performance monitoring that is compliant with
Technical Specification MEF 36. You can enable MEF-36-compliant performance
monitoring by configuring the measurement-interval statement at the [edit protocols
oam ethernet cfm performance-monitoring] or [edit protocols oam ethernet cfm
performance-monitoring sla-iterator-profiles profile-name] hierarchy level.
NOTE: When MEF-36-compliant performance monitoring is enabled, an
SNMP get next request for a variable might not fetch the current value
unless an SNMP walk is performed before performing the get next request.
This limitation applies only to the current statistics for delay measurement,
loss measurement, and synthetic loss measurement.
When MEF-36-compliant performance monitoring is enabled:
•
The output for the field Current delay measurement statistics might display a
measurement interval of 0 (zero) and an incorrect timestamp until the first cycle
time has expired.
•
Supported data TLV size for performance monitoring protocol data units (PDUs) is
1386 bytes when MEF-36-compliant performance monitoring is enabled. The TLV
size is 1400 bytes in legacy mode.
•
The maximum configurable value for the lower threshold bin is 4,294,967,294.
•
Frame loss ratio (FLR) is excluded in loss measurements during period of
unavailability for synthetic loss measurement only. In case of loss measurement,
FLR is included even during period of unavailability.
•
During a period of loss of continuity (adjacency down), although SOAM PDUs are
not sent, FLR and availability calculations are not stopped. These calculations are
performed with the assumption of 100% loss.
•
The number of SOAM PDUs that are sent during the first measurement interval might
be less than expected. This is because of a delay in detecting the adjacency state
at the performance monitoring session level.
•
The number of SOAM PDUs transmitted during a measurement interval for a cycle
time of 100 ms might not be accurate. For example, in a measurement interval of
two minutes with a cycle time 100 ms, the SOAM PDUs transmitted might be in the
range of 1198—2000.
When MEF-36-compliant performance monitoring is disabled, the show oam ethernet
connectivity-fault-management maintenance-domain sla-iterator-history
maintenance-domain md-name maintenance-association ma-name mep mep-id
Copyright © 2016, Juniper Networks, Inc.
81
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
sla-iterator profile-name command displays 32 records from this Junos OS release
onward. In earlier releases, the command displays 16 records.
•
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.
•
Ethernet loss measurement counter support for each class in a multiclass
environment—Junos OS supports Ethernet loss measurement (ETH-LM) for multiclass
services. The ETH-LM feature is used by operators to collect frame loss counter values
for ingress and egress service frames. Starting with Junos OS Release 14.2R3, the
ETH-LM feature is extended to support the frame loss measurement counters for each
class of packets in a multiclass environment. Counters for each class of packets are
supported for point-to-point services only.
NOTE: ETH-LM is currently supported for VPWS services only.
ETH-LM maintains counters based on the forwarding class and loss priority of a packet.
The loss priority determines the color of a packet—green indicates loss priority low for
committed information rate (CIR) and yellow indicates loss priority medium-high for
excess information rate (EIR). The color (green and yellow) counters are maintained
for each class of packets. Based on the counters supported on an interface, you can
configure the following accounting modes for Ethernet loss measurement:
•
Forwarding class-based accounting with color—In this mode, traffic is serviced based
on packet loss priority and forwarding class. Two counters–green and yellow–are
maintained for each forwarding class on each service interface. In this mode, an OAM
(operation, accounting, and maintenance) packet collects counters based on the
forwarding class.
To configure this mode of loss measurement accounting, use the
enable-multiclass-loss-measurement statement at the [set protocols oam ethernet
connectivity-fault-management performance-monitoring] hierarchy level for global
configuration or at the [set protocols oam ethernet connectivity-fault-management
performance-monitoring interface interface-name] hierarchy level for interface-level
configuration.
•
Forwarding class-based accounting without color—In this mode, traffic is serviced
based on the forwarding class only. Only one counter is maintained for each
forwarding class in each service interface.
To configure this mode of loss measurement accounting, use the
enable-multiclass-loss-measurement and colorless-loss-measurement statements
at the [set protocols oam ethernet connectivity-fault-management
performance-monitoring] hierarchy level for global configuration or at the [set
82
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
protocols oam ethernet connectivity-fault-management performance-monitoring
interface interface-name] hierarchy level for interface-level configuration.
•
Color-based accounting—In this mode, traffic is serviced based on the loss priority.
Two counters—green and yellow—are maintained for each service interface.
Color-based accounting is the default loss measurement mode and requires no
configuration.
•
Code point-based accounting—In this mode, traffic is serviced based on the 802.1p
priority bits. One counter is maintained for each code point (priority bit) on each
service interface. If there are user virtual LAN or 802.1p rewrite rules configured, loss
measurement accounting is done before applying the rewrite rules.
To configure this mode, use the code-point-based-lm-accounting statement at the
[set protocols oam ethernet connectivity-fault-management performance-monitoring]
hierarchy level for global configuration or at the [set protocols oam ethernet
connectivity-fault-management performance-monitoring interface interface-name]
hierarchy level for interface-level configuration.
NOTE: Code point-based accounting mode does not work if virtual LAN
pop or push is configured on the interface. If pop or push is configured,
the 802.1p bits are removed from the data packets. Therefore, in such
cases, you can use forwarding class-based accounting if a one-to-one
mapping exists between a forwarding class and the 802.1p bits value;
otherwise you can use the priority-based accounting mode.
•
Priority-based accounting—In this mode, four counters are maintained for each
forwarding class for each interface, with each counter corresponding to one of the
two colors. To configure this mode, use the priority-based-lm-accounting statement
at the [set protocols oam ethernet connectivity-fault-management
performance-monitoring] hierarchy level for global configuration or at the [set
protocols oam ethernet connectivity-fault-management performance-monitoring
interface interface-name] hierarchy level for interface-level configuration.
Routing Policy and Firewall Filters
•
New flexible offset firewall filter terms (MX Series routers with MPCs or MICs)—In
Junos OS releases earlier than Release 14.2, you configured firewall filter terms 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.
[See Firewall Filter Match Conditions for IPv6 Traffic].
•
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
Copyright © 2016, Juniper Networks, Inc.
83
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
[See Firewall Filter Match Conditions for IPv6 Traffic.]
84
•
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
walks 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.
•
Support for consistent load balancing for ECMP groups (MX Series routers with
MPCs)—Starting in Junos OS Release 14.2R2, on MX Series 3D Universal Edge Routers
with Modular Port Concentrators (MPCs) only, you can prevent the reordering of flows
to active paths in an ECMP group when one or more paths fail. Only flows that are
inactive are redirected. This feature applies only to Layer 3 adjacencies learned through
external BGP connections. It overrides the default behavior of disrupting all existing,
including active, TCP connections when an active path fails. Include the consistent-hash
statement at the [edit policy-options policy-statement policy-statement-name then
load-balance] hierarchy level. You must also configure a global per-packet
load-balancing policy.
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.]
•
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.
Copyright © 2016, Juniper Networks, Inc.
85
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
•
OSPF domain-id interoperability (MX Series)— Starting in Junos OS Release 14.2R4,
to enable interoperability with routers from other vendors, you can set the AS number
for domain-id attributes to 0 at the following hierarchical levels:
[edit routing-instances routing-instance name protocols ospf domain-id]
or
[edit policy-options community community name members]
CAUTION: Do not downgrade Junos OS after configuring the AS number
for domain-id attributes to 0. Set the AS number to a nonzero value and
commit the configuration before downgrading Junos OS.
Services Applications
86
•
Support for interim logging for NAT port block allocation (MX Series routers with
MS-MPCs/MS-MICs)—Starting in Junos OS Release 14.2R2, you can configure interim
logging for NAT with port translation on MX Series routers with MS-MPCs or MS-MICs.
Default logging sends a single log entry for ports allocated to a subscriber. These syslog
entries can be lost for long running flows. Interim logging triggers the re-sending of logs
at configured time intervals for active blocks that have traffic on at least one of the
ports of the block, ensuring that there is a recent syslog entry for active blocks. You
can specify interim logging by including the pba-interim-logging-interval statement at
the [edit interfaces interface-name services-options] hierarchy level.
•
Support for transmission of probes between a TWAMP client and a TWAMP server
(MX Series)—Starting in Junos OS Release 14.2R2, you can configure an MX Series
router that contains a Packet Forwarding Engine with 16-port 10-Gigabit Ethernet MPCs,
FPCs (MPCs), MPC3Es, or MPC4Es to function as a Two-Way Active Measurement
Protocol (TWAMP) client. A TWAMP client is a device that sends probe or test packets
and functions as the generator or initiator of the probes. A TWAMP server is a device
that receives the probes from the client and functions as the reflector or the receiver.
A client opens a TCP connection with the server on a well-known port, which is port
number 862. The host that initiates the TCP connection takes the roles of the
control-client and (in the two-host implementation) the session-sender. Such a device
is also called the TWAMP client. The host that acknowledges the TCP connection
accepts the roles of a server and (in the two-host implementation) the session-reflector.
Such a device is also called the TWAMP server.
•
Support for logging flow monitoring records with version 9 and IPFIX templates for
NAT events (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS
Release 14.2R2, you can configure MX Series routers with MS-MPCs and MS-MICs to
log network address translation (NAT) events using Junos Traffic Vision (previously
known as J-flow) version 9 or IPFIX (version 10) template format. NAT event logger
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
generates messages in flow monitoring format for various NAT events, such as the
creation of a NAT entry, deletion of a NAT entry, and for invalid NAT processing (such
as NAT address pools or address values being exhausted for allocation). These events
also support NAT64 translations (translation of IPv6 addresses to IPv4 addresses),
binding information base (BIB) events, and more detailed error generation. The
generated records or logs for NAT events in flow template format are sent to the
specified host or external device that functions as the NetFlow collector. Until Junos
OS Release 14.2R1, MS-PIC uses the system logging protocol (syslog) to generate
session logging. System log messages can be sent directly from the MS-PIC to an
external system-logging server. For this transmission of syslogs to work properly, the
services PIC interface must have an IP address and appropriate system logging options
configured.
•
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 unit-number] 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
Copyright © 2016, Juniper Networks, Inc.
87
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
statistics by using the show services inline ip-reassembly statistics <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.
88
•
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.
•
Support for PCP version 2 (MX Series)—Starting in Release 14.2R3, Junos OS supports
Port Control Protocol (PCP) version 2, defined by IETF RFC 6887. PCP version 2 uses
the client once for authentication. Junos OS is able to decode and process version 2
and version 1 messages. There are no CLI changes for PCP version 2 support.
•
Support for RPM probes with IPv6 sources and destinations (MX Series routers with
MPCs)—Starting in Junos OS Release 14.2R3, the RPM client router (the router or switch
that originates the RPM probes) can send probe packets to the RPM probe server (the
device that receives the RPM probes) that contains an IPv6 address. To specify the
destination IPv6 address used for the probes, include the target (url ipv6-url | address
ipv6-address) statement at the [edit services rpm probe owner test test-name] hierarchy
level. You can also define the RPM client or the source that sents RPM probes to contain
an IPv6 address. To specify the IPv6 protocol-related settings and the source IPv6
address of the client from which the RPM probes are sent, include the inet6-options
source-address ipv6-address statement at the [edit services rpm probe owner test
test-name] hierarchy level.
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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 209.]
•
OpenFlow v1.3.1 with IPv6 match conditions (MX80 3D Universal Edge, MX240,
MX480, and MX960 3D Universal Edge Routers)—Starting with Junos OS Release
14.2R3, the MX80 3D Universal Edge, MX240, MX480, and MX960 3D Universal Edge
routers support IPv6 match conditions OFPXMT_OFB_IPV6_SRC and
OFPXMT_OFB_IPV6_DST.
[See OpenFlow v1.3.1 Compliance Matrix for Devices Running Junos OS.]
•
OVSDB schema update (MX Series)—Starting with Junos OS Release 14.2R4, the
OVSDB schema for physical devices version that is implemented on the MX Series
routers is version 1.3.0. In addition, the schema now supports the multicast MACs local
table.
[See Open vSwitch Database Schema For Physical Devices.]
•
Destination MAC address rewrites for OpenFlow (MX80, MX240, MX480, and
MX960)—Some types of network equipment that function as routers accept and
handle packets only if the destination MAC address in the packet is the same as the
MAC address of the Layer 3 interface on which the packet is received. To interoperate
with these routers, connected devices must also be able to rewrite the destination
MAC address of an incoming packet. Starting with Junos OS Release 14.2R6, an
OpenFlow controller can configure an MX Series router that supports OpenFlow to
rewrite the destination MAC address of an incoming packet.
[See Understanding How the OpenFlow Destination MAC Address Rewrite Action Works.]
Copyright © 2016, Juniper Networks, Inc.
89
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Subscriber Management and Services
NOTE: Subscriber management is not supported in Release 14.2R6.
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 Release 14.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.]
•
90
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
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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, starting 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]
•
•
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 can 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
Copyright © 2016, Juniper Networks, Inc.
91
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
statistics <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.]
92
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
System Management
•
Statement introduced to deny hidden commands—Starting in Release 14.2R4, Junos
OS allows users to deny hidden commands to all users except root. To deny hidden
commands to all users except root, use the set system no-hidden-commands statement
at the edit hierarchy level.
User Interface and Configuration
•
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
•
•
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
VRF localization (MX Series with MPCs)—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
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
Copyright © 2016, Juniper Networks, Inc.
93
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
•
Integrating EVPN with VXLAN for Layer 2 data center interconnect (MX Series with
MPCs and MICs only)—Virtual Extensible Local Area Network (VXLAN) is a technology
that provides intra data center connectivity using a tunneling scheme to stretch Layer
2 connections over an intervening Layer 3 network.
The Ethernet VPN (EVPN) technology, on the other hand, provides a solution for
multipoint Layer 2 VPN services with advanced multihoming capabilities, using BGP
control plane over MPLS/IP network.
EVPN provides mechanisms for next generation DCI by adding extended control plane
procedures to exchange Layer 2 MAC address and Layer 3 IP address information
among the participating Data Center Border Routers (DCBRs). EVPN with its advanced
features like active-active redundancy, aliasing, and mass MAC withdrawal helps in
addressing the DCI challenges, such as seamless VM mobility and optimal IP routing,
thus making it essential to provide VXLAN solutions over EVPN.
•
Leveraging DPCs for EVPN deployment (MX Series with DPCs)—Starting with Junos
OS Release 14.2R3, DPCs can be leveraged to provide support for Ethernet VPN (EVPN)
functionality. Earlier, the EVPN functionality was provided by MX Series routers with
MPC and MIC interfaces only.
The DPC support for EVPN is provided with the following considerations:
•
•
•
94
DPCs provide support for EVPN in the active-standby mode of operation including
support for the following:
•
EVPN instance (EVI)
•
Virtual switch (VS)
•
Integrated routing and bridging (IRB) interfaces
DPCs intended for providing the EVPN active-standby support should be the customer
edge (CE) device-facing line card. The provider edge (PE) device interfaces in the
EVPN domain should use only MPC and MIC interfaces.
Overlay ping and traceroute functionality for VXLAN tunnels (MX Series)—Starting
in Junos OS Release 14.2R4, two new CLI commands supporting ping and traceroute
troubleshooting functionality are provided to debug VXLAN overlay tunnels: ping overlay
vni vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst and traceroute overlay vni
vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst. Use the ping overlay and
traceroute overlay commands to validate and verify the presence of the VXLAN tunnel
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
endpoints within the context of the overlay VXLAN Network Identifier or VXLAN
Segment ID (VNI) segment.
Related
Documentation
•
EVPN with VXLAN data plane encapsulation (MX Series)—Starting in Junos OS
Release 14.2R4, MX Series routers can use EVPN with VXLAN encapsulation to provide
Layer 2 connectivity for end stations within a Virtualized Network (VN) created by the
Contrail virtualization software. The end stations consist of virtual hosts connected to
the virtualized server, and non-virtualized bare metal servers connected to top-of-rack
platforms. MX Series routers also function as default gateways for the inter-VN traffic
among end stations that belong to different VNs. EVPN is used as a Layer 2 overlay
solution to provide Layer 2 connections over the IP underlay for the endpoints within
a VN whenever Layer 2 connectivity is required by an end station.
•
IPv6 support over IRB interfaces for EVPN (MX Series)—Starting in Junos OS Release
14.2R5, the Ethernet VPN (EVPN ) integrated routing and bridging (IRB) solution
supports IPv6 and the Neighborhood Discovery Protocol (NDP). NDP is used by IPv6
nodes on the same link to discover each other’s presence, determine each other’s Link
Layer addresses, find routers, and maintain reachability information about the paths
to active neighbors. IPv6 addresses over IRB for EVPN is supported for unique VLAN
EVPN instances and for virtual switches with protocol EVPN instances.
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Changes in Behavior and Syntax
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.2R6 for the M Series,
MX Series, and T Series.
•
High Availability (HA) and Resiliency on page 96
•
Interfaces and Chassis on page 96
•
Layer 2 VPNs on page 97
•
MPLS on page 97
•
Multicast on page 98
•
Network Address Translation (NAT) on page 99
•
Network Management and Monitoring on page 99
•
IPv6 on page 99
•
Routing Policy and Firewall Filters on page 99
•
Routing Protocols on page 100
Copyright © 2016, Juniper Networks, Inc.
95
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Security on page 102
•
Services Applications on page 102
•
Subscriber Management and Services on page 104
•
User Interface and Configuration on page 106
High Availability (HA) and Resiliency
•
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.]
•
Improved command output for determining GRES readiness in an MX Series Virtual
Chassis (MX Series with MPCs)—Starting in Junos OS Release 14.2R3, the request
virtual-chassis routing-engine master switch check command displays the following
output when the member routers in a Virtual Chassis are ready to perform a graceful
Routing Engine switchover (GRES):
{master:member0-re0}
[email protected]> request virtual-chassis routing-engine master switch check
Switchover Ready
In earlier releases, the request virtual-chassis routing-engine master switch check
command displays no output to confirm that the member routers are ready for GRES.
The output of the request virtual-chassis routing-engine master switch check command
has not changed when the member routers are not yet ready for GRES.
Interfaces and Chassis
•
96
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
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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.
•
Support for fabric self-pings and Packet Forwarding Engine liveness in single-chassis
systems (T Series)—Starting in Junos OS Release 14.2R6, T Series single-chassis
systems support the fabric self-ping and Packet Forwarding Engine liveness
mechanisms to detect fabric degradation and avoid a traffic black hole. If any error is
detected by these two mechanisms, the fabric manager raises a fabric degraded alarm
and initiates recovery by restarting the FPC. In a single-chassis system, FPC restart is
enabled by default, unlike in a multichassis system where FPC restart is disabled by
default.
Layer 2 VPNs
•
Support for hot standby pseudowire for VPLS instances with LDP (MX
Series)—Starting with Junos OS Release 14.2R6, you can configure a routing device
running a VPLS routing instance configured with the Label Distribution Protocol (LDP)
to indicate that a hot-standby pseudowire is desired upon arrival of a PW_FWD_STDBY
status-tlv. Include the hot-standby-vc-on statement at the [edit routing instances
routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address
pseudowire-status-tlv] hierarchy level.
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
Copyright © 2016, Juniper Networks, Inc.
97
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
[email protected]> show pim join summary | display xml
[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>
98
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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.
Network Management and Monitoring
•
Enhancement for SONET interval counter (M Series, MX Series, and T
Series)—Starting with Junos OS Release 14.2R6, only the Current Day Interval Total
output field in the show interfaces interval command for SONET interfaces is reset
after 24 hours. In addition, the Previous Day Interval Total output field displays the last
updated time in hh:mm.
[See show interfaces interval.]
IPv6
•
IPv6 addresses with padded zeros in MIC or MS-MPC system log messages (M Series,
MX Series, and T Series)—Starting with Junos OS Release 14.2R4, all system log
messages originating from MIC or MS-MPC line cards display padded zeros in IPv6
addresses to make them compatible with MS-DPC line cards. Earlier, the system log
messages from MIC or MS-MPC line cards displayed IPv6 addresses with ’::’ instead
of padded zeros.
Routing Policy and Firewall Filters
•
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
Copyright © 2016, Juniper Networks, Inc.
99
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
configured with a very large number of filters to display information about a subset of
filters more efficiently.
[See show firewall.]
•
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.]
•
100
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.
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
The all keyword is introduced for the following clear commands:
•
•
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
Support for RFC 6996, RFC 7300, and Internet draft-ietf-idr-as0-06—Beginning
with Junos OS Release 14.2, RFC 6996, Autonomous System (AS) Reservation for Private
Use, RFC 7300, Reservation of Last Autonomous System (AS) Numbers, and Internet
draft-ietf-idr-as0-06 are supported.
RFC 6996, Autonomous System (AS) Reservation for Private Use, defines the range of
the reserved, private AS numbers. The set of reserved 16-bit AS numbers is in the range
from 64,512 through 65,535 and the reserved 32-bit AS numbers range from
4200000000 through 4294967294. Even though the use of the last 16-bit AS numbers
are reserved, private AS number 65535 is allowed in Junos OS configurations. However,
we do not recommend using this restricted AS number.
RFC 7300, Reservation of Last Autonomous System (AS) Numbers, and the Internet
draft draft-ietf-idr-as0-06 restrict the use of 4-byte AS number 4294967295UL, and
AS number 0 in a configuration. When you use these restricted AS numbers, the commit
operation fails.
Copyright © 2016, Juniper Networks, Inc.
101
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[See 4-Byte Autonomous System Numbers Overview.]
•
BGP hides a route received with a label block size greater than 256—Beginning with
Junos OS Release 14.2R2, when a BGP peer (running Junos OS) sends a route with a
label block size greater than 256, the local speaker hides the route and does not
re-advertise this route. The output of show route detail/extensive hidden/all displays
the hidden route and states the reason as label block size exceeds max supported value.
In earlier Junos releases, when a peer sent a route with a label block size greater than
256, the routing protocol process (rpd) terminated abnormally.
Security
•
Packet types added for DDoS protection L2TP policers (MX Series with MPCs, T4000
with FPC5)—The following eight packet types have been added to the DDoS protection
L2TP protocol group to provide flexibility in controlling L2TP packets:
cdn
scccn
hello
sccrq
iccn
stopccn
icrq
unclassified
Previously, no individual packet types were available for this protocol group and all
L2TP packets were policed the same based on the aggregate policer value. The default
values for the bandwidth and burst policers for all packet types is 20,000 pps. The
default recover-time is 300 seconds for each of the L2TP packet types.
•
BGP route is hidden when AS path length is more than the configured maximum AS
size —Beginning with Junos OS Release 14.1, BGP hides a route when the length of the
AS path does not match the number of ASs in the route update. In earlier Junos releases
when a route with AS path size over 2048 was advertised, it could cause session flaps
between BGP peers because of the mismatch. Therefore, to avoid session flaps, such
routes are now hidden by Junos. You can see this behavior when bgp-error-tolerance
is configured.
If you want BGP to advertise the hidden route to an OSPF neighbor, we recommend
to add the AS path statically in the default route configuration. For example:
[edit routing-instances instance-name routing options]
[email protected]# set aggregate route 0.0.0.0/0 as-path path 1267
Services Applications
102
•
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.
•
Interoperation of ingress sampling and PIC-based flow monitoring (MX Series)—If
PIC-based flow monitoring is enabled on an ms- logical interface, a commit check
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
error occurs when you attempt to configure ingress traffic sampling on that particular
ms- logical interface. This error occurs because a combination of ingress sampling and
PIC-based flow monitoring operations on an ms- logical interface causes undesired
flow monitoring behavior and might result in repeated sampling of a single packet. You
must not configure ingress traffic sampling on ms- logical interfaces on which PIC-based
flow monitoring is enabled.
•
Change in support for service options configuration on service PICs at the MS and
AMS interface levels (MX Series)—Starting in Junos OS Release 14.2R3, when a
multiservices PIC (ms- interface) is a member interface of an AMS bundle, you can
configure the service options to be applied on the interface only at the ms- interface
level or the AMS bundle level by including the services-options statement at the [edit
interfaces interface-name] hierarchy level at a point in time. You cannot define service
options for a service PIC at both the AMS bundle level and at the ms- interface level
simultaneously. When you define the service options at the MS level or the AMS bundle
level, the service options are applied to all the service-sets on the ms- interface or AMS
interface defined at ms-fpc/pic/port.logical-unit or amsN, respectively.
•
Generation of mspmand core file for flow control (MX Series routers with MS-MICs
and MS-MPCs)—Starting with Junos OS Release 14.2R3, instead of an eJunos kernel
core file, the multiservices PIC management daemon core file is generated when a
prolonged flow control occurs and when you configure the setting to generate a core
dump during prolonged flow control (by using the dump-on-flow-control option). The
watchdog functionality continues to generate a kernel core file in such scenarios.
•
Changes in the format of session open and close system log messages (MX Series
routers with MS-MICs and MS-MPCs)—Starting with Junos OS Release 14.2R3, with
the Junos OS Extension-Provider packages installed and configured on the device for
MS-MPCs and MS-MICs, the formats of the MSVCS_LOG_SESSION_OPEN and
MSVCS_LOG_SESSION_CLOSE system log messages are modified to toggle the order
of the destination IPv4 address and destination port address displayed in the log
messages to be consistent and uniform with the formats of the session open and close
logs of MS-DPCs.
The following is the modified format of the MSVCS_LOG_SESSION_OPEN and
MSVCS_LOG_SESSION_CLOSE system log messages:
month date hh:mm:ss syslog-server-ip-address yyyy-mm-dd hh:mm:ss
{NAT-type}<MSVCS_LOG_SESSION_CLOSE or MSVCS_LOG_SESSION_OPEN>:App:
application, source-interface-name fpc/pic/port\address in hexadecimal format
source-address:source-port source-nat-information ->
destination-address:destination-port destination-nat-information (protocol-name)
The following is an example of the session closure message generated for MS-MPCs
and MS-MICs:
Nov 26 13:00:07 10.137.159.1 2014-11-26 07:22:44:
{Dynamic-NAT-64-SS-NHS-1}MSVCS_LOG_SESSION_CLOSE: application:none, ae4.454
2402:8100:1:160:1:2:d384:463c:36822 [49.14.64.37:12261] -> [141.101.120.14]
64:ff9b::8d65:780e:80 (TCP)
•
Optional inclusion of Flags in DTCP LIST messages (MX Series)—Starting in Junos
OS Release 14.2R3, the Flags field is not a required parameter in the DTCP LIST
Copyright © 2016, Juniper Networks, Inc.
103
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
message. The LIST request is not rejected if the LIST message does not contain the
Flags field. If the DTCP LIST message contains the Flags field, the value of that field
is processed. If the LIST message does not contain the Flags field, the CRITERIA field
parameter is used for the Flags field.
•
Support for bouncing service sets for dynamic NAT (MX Series with MS-MPCs and
MS-MICs)— Starting in Junos OS Release 14.2R2, for service sets associated with
aggregated multiservices (AMS) interfaces, you can configure the
enable-change-on-ams-redistribution statement at the [edit services service-set
service-set-name service-set-options] hierarchy level to enable the service set to be
bounced (reset) for dynamic NAT scenarios (dynamic NAT, NAT64, and NAT44) when
a member interface of an AMS bundle rejoins or a member interface failure occurs.
When a member interface fails, the application resources (NAT pool in the case of
dynamic NAT scenarios) and traffic load need to be rebalanced. For application
resources to be rebalanced, which is the NAT pool for dynamic NAT environments, the
NAT pool is split and allocated by the service PIC daemon (spd).
Subscriber Management and Services
NOTE: Subscriber management is not supported in 14.2R6.
Although present in the code, the subscriber management features are not
supported in Junos OS Release 14.2R6. 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
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.
104
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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
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.
•
LAC configuration no longer required for L2TP tunnel switching with RADIUS
attributes (MX Series)—Starting in Junos OS Release 14.2R3, when you use Juniper
Networks VSA 26-91 to provide tunnel profile information for L2TP tunnel switching,
you no longer have to configure a tunnel profile on the LAC. In earlier releases, tunnel
Copyright © 2016, Juniper Networks, Inc.
105
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
switching failed when you did not also configure the LAC, even when the RADIUS
attributes were present.
•
Change to show services l2tp tunnel command (MX Series)—Starting in Junos OS
Release 14.2R4, the show services l2tp tunnel command also includes in its display
tunnels that have no active sessions. In earlier releases, the command does not display
tunnels without any active sessions.
User Interface and Configuration
•
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.]
•
New warning message for the configurational changes to extend-size (M Series, MX
Series, and T Series)—Starting with Junos OS Release 14.2R5, any operation on the
system configuration-database extend-size configuration statement such as, deactivate,
delete, or set, generates the following warning message:
Change in 'system configuration-database extend-size' will be effective at next reboot
only.
Related
Documentation
•
New and Changed Features on page 59
•
Known Behavior on page 106
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Known Behavior
This section contains the known behavior, system maximums, and limitations in hardware
and software in Junos OS Release 14.2R6 for the M Series, MX Series, and T Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
106
•
Hardware
•
High Availability (HA) and Resiliency
•
MPLS
•
Network Management and Monitoring
•
Routing Protocols
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
•
Software-Defined Networking (SDN)
•
Subscriber Management and Services
•
System Logging
Hardware
•
MIC-3D-8OC3-2OC12-ATM Revision 22 is supported only by the following Junos OS
releases:
•
Junos OS Release 12.3—12.3R9 and later
•
Junos OS Release 13.3—13.3R6 and later
•
Junos OS Release 14.1—14.1R4 and later
•
Junos OS Release 14.2—14.2R3 and later
•
Junos OS Release 15.1 and later
You must upgrade to a supported Junos OS release to use MIC-3D-8OC3-2OC12-ATM
Revision 22 and later.
High Availability (HA) and Resiliency
•
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
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. PR1014295
MPLS
•
If an SRLG is associated with a link used by an ingress LSP in the router, then on deleting
the SRLG configuration from that router, the SRLG gets removed from the SRLG table
only on the next reoptimization of the LSP. Until then, the output displays Unknown-XXX
instead of the SRLG name and a non zero srlg-cost of that SRLG for the run show mpls
srlg command.
Network Management and Monitoring
•
On the MX Series, when there is no traffic, the Qdepth statistics output field in the show
class-of-service fabric statistics detail command displays count 0 for all the subfields,
except the Max count subfield.
•
On MX Series routers, when you configure multiple prefix lists for endpoint independent
filtering, all the prefix lists do not get enabled. As a workaround, to configure multiple
prefix lists for endpoint independent filtering, ensure that you use a single commit
command to commit the configuration of all the defined prefix lists. If you want to
Copyright © 2016, Juniper Networks, Inc.
107
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
include additional prefixes in the prefix lists, delete all the existing prefix lists and add
them again.
Routing Protocols
•
Junos OS displays the configured BGP group description pushed by the remote
procedure call (RPC) in the show | compare output even after commit is performed.
This occurs due to the use of terminating double quotes in the string inputs, in the RPC
XML format. Therefore, as a workaround do not include terminating quotes in strings
in any RPC XML configuration to avoid this issue. PR1066084
Software-Defined Networking (SDN)
•
On MX Series routers running OpenFlow v1.3.1 software, the output for the show
openflow flows command displays IPv6-related fields. However, the Junos OS
implementation of OpenFlow v1.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 v1.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 v1.3.1 software, the ADPC might create a core
file. Configure enhanced IP network services mode to disable the ADPC. PR988256
Subscriber Management and Services
•
The show ppp interface interface-name extensive and show interfaces pp0 commands
display different values for the LCP state of a tunneled subscriber on the LAC. The
show ppp interface interface-name extensive command displays STOPPED whereas
the show interfaces pp0 command displays OPENED (which reflects the LCP state
before tunneling). As a workaround, use the show ppp interface interface-name extensive
command to determine the correct LCP state for the subscriber.
•
On MX Series routers, when you configure the subscriber-awareness statement on a
service set by committing the set services service-set service-set-name
service-set-options subscriber-awareness statement, the service sessions fail to create.
To avoid this issue, on MX Series routers that support the Service Control Gateway
solution, ensure that the Junos OS Mobility package software is installed on the router.
The Service Control Gateway solution is supported only in 14.1X55 releases. For Junos OS
Releases 14.2, and 15.1, ensure that the subscriber-awareness statement is not set.
System Logging
Related
Documentation
108
•
On MX Series routers, when you configure a rate limit for system log messages by
setting the message-rate-limit statement for a multiservices interface, ensure that the
syslog host option for that interface is configured. This configuration ensures that the
system log statistics reflect the rate limit set for the interface.
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R6
for the M Series, MX Series, and T Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
Forwarding and Sampling on page 109
•
General Routing on page 110
•
High Availability (HA) and Resiliency on page 113
•
Infrastructure on page 113
•
Interfaces and Chassis on page 113
•
J-Web on page 114
•
Layer 2 Features on page 114
•
MPLS on page 114
•
Network Management and Monitoring on page 115
•
Platform and Infrastructure on page 115
•
Routing Protocols on page 116
•
Services Applications on page 117
•
User Interface and Configuration on page 117
•
VPNs on page 117
Forwarding and Sampling
•
When VRRP is configured on Trio-based MX interfaces, Static mac entries are installed
on PFE in the MAC-DB as part of the mac-filter installations. RPF mib-walk triggering
a walk over the MAC MIB entry(Walk over the static mac entries with no OIDs) causes
the error message. During the walk, it is expected that no entries are read from static
mac-db entries, however the EODB is not set to indicate MAC-DB walk has ended. This
error log does not have any functional impact on the RPF mib-walk. mib2d[xxx]:
MIB2D_RTSLIB_READ_FAILURE: check_rtsock_rc: failed in reading mac_db: 0 (Invalid
argument) mib2d[xxx]: SNMP_GET_ERROR1: macStatsEntry getnext failed for interface:
index1 ge-*/*/* (Invalid argument) PR1042610
•
On Trio-based platforms, when the Layer 3 packets destined to an Integrated Routing
and Bridging (IRB) interface and then hit the underlying Layer 2 logical interfaces (IFLs),
due to the egress feature list of the Layer 2 IFLs may get skipped, the features under
the family bridge (for example, the firewall filter) on the Layer 2 interfaces may not be
executed. PR1073365
Copyright © 2016, Juniper Networks, Inc.
109
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Flow-based router filter optimization. PR1107457
General Routing
•
Loopback filter handling for Openflow Traffic. PR837136
•
When both Routing Engines in a dual-Routing Engine system reboot too quickly with
GRES enabled, 'ipsec-key-management' process would require a manual restart.
PR854794
•
On M series routers, packets are dropped upon setting AE LP discard-data knob,
however there is no CLI command to display the drop count. PR876190
•
This is a product limitation. Necessary documentation can be done as necessary Release
Notes or Enhancement Requests and assigned accordingly. PR882695
•
Kernel messages "SO_RTBL_INDEX " are seen continuously when LDP session is down.
The log messages were meant for debugging purpose. It is a harmless message. <
messages example > /kernel: setsocketopts: setting SO_RTBL_INDEX to 0 PR888162
•
Checksum error is seen on ICMP reply when 'sequence, data' field in request set to '0'.
PR898487
•
Minor memory leaks might occur if you add and delete the same multi-VLAN flow on
the order of 100,000 such add and delete operations. PR905620
•
On Junos platform, a license service may crash during license check process. At that
time, a core file will be generated by license-check daemon. You may also see multiple
core files in the system. PR918682
•
OVSDB/NSX: NSX controller does not delete stale VTEP+MAC info PR962949
•
Traceroute through an interface-services style AMS service-set fails under some
configurations. PR966171
•
In scale DHCP subscribers scenario (e.g, 54K dual-stack DHCPv4/DHCPv6), graceful
Routing Engine Switchover (GRES) is configured. If RE switchover occurs, after that
execute the command "[email protected]> show dynamic-configuration" many times,
large-scale DHCP or DHCPv6 subscribers might be terminated. PR968021
•
Openflow 1.3: packet was not received on interface after restart firewall daemon.
PR969520
110
•
Trigger for seeing fabric errors: --------------------------------- Have traffic between 2
FPCs. Offline the destination FPC Result of the trigger: ----------------------- Fabric
errors like "Fo: Request timeout errors" will be seen on the source FPC. As the source
FPC has outstanding requests to the offlined destination FPC, the requests timeout
and hence these errors are seen. These messages are expected. PR971956
•
Query port information duration_nsec and duration_sec always shows 0. PR978321
•
OVSDB/NSX: nsx switch port still showed up after deactivate interface from routing
instance. PR979695
•
ovsdb/nsx: traffic still passing when deactivate protocol ovsdb. PR980577
•
Flow statistics still show packet increasing when the output port link is down. PR987753
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
On devices running OpenFlow 1.3.1, ADPC line cards are not supported. Please configure
IP-enhanced network services to disable ADPC line cards. PR988256
•
When a MAC moves from one VTEP to another VTEP, it is not learnt behind the new
VTEP until the old VTEP ages out this MAC. This will cause traffic for this MAC to black
hole until it ages out on the old VTEP. PR988270
•
An NSX controller occasionally overrides an existing local MAC with a remote MAC of
the same address. If a hardware VTEP in a Junos OS network detects such a condition
(that is, it receives a remote MAC from the NSX controller that conflicts (matches)
with an existing local MAC), the hardware VTEP in a Junos OS network accepts the
remote MAC and stops publishing the local MAC to the NSX controller. PR991553
•
On MX series router, when a instance type is changed from VPLS to EVPN, and in the
same commit an interface is added to the EVPN instance, the newly added EVPN
interface might not be able to come up. PR1016797
•
In BGP MVPN RPT-SPT mode, on an egress PE with an interface with static IGMP v2
configured and directly connected IGMP v2 hosts, the IGMP reports can be treated as
multicast data packets by PFE and it can trigger data events (IIF-MISMATCH) that can
create undesirable (S,G) states. These states are usually harmless but, in a high scale,
can result in resource utilization. It is worth noting that in BGP MVPN RPT-SPT mode,
directly connected receivers and senders are not officially supported for other reasons
(due to lack of SPT-Switch capability). PR1021501
•
When using large configs with many BGP peers and a high level of logging, RPD
scheduler slips may be logged in the syslog messages file. PR1028608
•
On MPC5E card, the drops on ingress are unaccounted when executing CLI command
"show interfaces extensive". After configuring the "no-flow-control" knob, the drops
are visible. PR1037632
•
The static/static access routes pointing to an unnumbered interface are getting added
in the routing table even if the interface is down. In this case, if graceful Routing Engine
switchover (GRES) is disabled, this type of routes will never be added in routing table
after Routing Engine switchover. PR1064331
•
On MX routers with MPC2E-3D-NG/MPC3E-3D-NG/MPC5/MPC6 line cards, the
Ethernet frame loss measurement (ETH-LM) feature does not work. PR1064994
•
Class 4 (32W) Optics are not supported on MPC4E (2CGE+8XGE). Upon insertion and
removal of a Class 4 optic, the TX laser will remain powered-off, even when a supported
optic is inserted. PR1068269
•
ICMP echo_reply traffic with applications like IPsec will not work with the MS-MIC and
MS-MPC cards in an asymmetric traffic environment since these cards employ a stateful
firewall by default. The packet will be dropped at the stateful firewall since it sees an
ICMP Reply that has not matching session. PR1072180
•
MX1 MX2 \ / spine switch layer / \ TOR1 TOR2 With EPVN VXLAN configured on TOR
and MX running Junos OS software and spine switches configured for IBGP to GW layer
and ebgp to TOR layer, no-nexthop-change is typically configured on spine switch (as
the switch doesn't participate in EVPN and is part of the IP underlay) and VTEP tunnels
are established between TOR and MX devices. If this knob is changed on spine switch,
Copyright © 2016, Juniper Networks, Inc.
111
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
spine switch will announce itself to be the EVPN protocol next-hop and new VTEP
tunnels will be setup between MX/TOR to spine switch, but the old VTEP tunnels
between TOR and MX won't be deleted. It is not expected that the status of knob will
be changed on spine switch as it doesn't have L2 state to support forwarding. Fixing
this symptom would also add complexity to routing control plane, hence there's no
plan to fix it. PR1114809
112
•
In some cases at high pps, the CPU utilization reported in the output of the "show
services service-sets summary" command may fluctuate but there is no impact to
functionality. PR1127433
•
5M PPTP control + Data sessions are not supported on PIC. CPU's are busy with closing
sessions and going to Prolong Flow control mode. CPU throttling can control incoming
session rate but can't control teardown session rate. We can say that we don't support
these scale values. Note : We have tested 2M-4M PPTP control + Data sessions test
few times for 48 hours and the PFC cores were not seen with those tests. PR1140832
•
MX routers with MPC3E NG hardware prior to 15.1 will see cosmetic messages like: Feb
1 11:55:41.799 JTAC-re0 : %PFE-3: fpc3 IFFPC: 'IFD Ether uint8 set' (opcode 54) failed
Feb 1 11:55:41.882 JTAC-re0 : %PFE-3: fpc3 ifd 312; Ether uint8 set error (7) Feb 1
11:55:41.954 JTAC-re0 : %PFE-3: fpc3 MIC: unknown option 207, ifd 312/xe-3/0/8,
cmic_eth_uint8_set .. upon commit of changes to [edit interfaces] configuration. This
issue was fixed for MPC4E hardware under PR/1097262, but is not going to be fixed
for MPC3E. PR1157861
Copyright © 2016, Juniper Networks, Inc.
Known Issues
High Availability (HA) and Resiliency
•
During a router hardware upgrade procedure, in a dual REs system, the newly installed
Routing Engine (RE) may overwrite the other RE configuration with the factory default
configuration. As a result, both REs may boot-up in "Amnesiac" mode. This situation
can occur under following conditions: - RE0 has default factory configuration and, RE1 has "commit synchronize" enabled - Both RE0 and RE1 boot-up simultaneously,
or - RE0 is UP and running and RE1 is restarted. PR909692
Infrastructure
•
The 'show system memory' command does not work on 64 bit systems. The
implementation requires the use of loadable kernel module to gather data. This module
has known issues and has been the root cause of numerous kernel panics. In addition
the pmap utility which provides the data for the cli has known, rare, crashes on 32 bit
kernels. In the case when the pmap utility crashes no information will be reported by
the CLI. PR883953
Interfaces and Chassis
•
During an RE switchover in which OAM-AH (LFM) is configured, the peer router may
see syslog entries which indicate an LFM session new state of up. These logs are
harmless however rightfully cause concern that the LFM session had dropped, which
is not the case. PR775616
•
RE might panic and go to db prompt when a member link of an Aggregated Ethernet
(AE) bundle is moved out of the bundle and the link are configured separately in it in
a single commit. PR892129
•
For a VRRP interface, if illegal speed is configured (for example 100M is configured to
a GE only interface), there is possibility that the virtual IP addresses for VRRP being
removed from the master VRRP router once commit. PR901803
•
Kernel crash may happen when a router running a junos install with the fix to PR 937774
is rebooted. This problem problem will not be observed during the upgrade to this junos
install. It occurs late enough in the shutdown procedure that it shouldn't interfere with
normal operation. PR956691
•
When AE interface is made down, VRRP sessions over that AE does not move to init
state directly in case of scaled configuration. Because delay in "interface down" vrrp
session detects adjacency down first and moves to master state. Subsequently when
interface down is reported vrrp session moves to init state. PR959672
•
The VRRP version change is a catastrophic event. Runtime change in VRRP version
may result in significant amount of traffic drop, duplication of packets, false state
change alarm etc. Changing version on a production router is not advisable. PR960395
•
On MX Series router, in rare condition, the kernel might crash and the router will go in
db prompt when router reboots. PR993978
•
When configuring MX Virtual-chassis system, pace the creation of VCP ports PR1052821
Copyright © 2016, Juniper Networks, Inc.
113
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Whenever the MIC 10x 1GE(LAN) SFP is offlined, there may be times when the certain
PCI ERROR messages are seen as part of the messages. This happens if the PCI thread
is running and thread_yield() is invoked when the MIC is being offlined. These error
messages are expected due to the thread_yield. These messages are harmless and
shouldn't affect the PCI access once the MIC is brought online. PR1067083
•
Deactivating/activating logical interfaces may cause BGP session flapping when BGP
is using VRRP VIP as source address. This is caused by a timing issue between dcd and
VRRP overlay file. When dcd reads the overlay file, it is not the updated one or yet to
be updated. This results in error and dcd stops parsing VRRP overlay file. PR1089576
J-Web
•
When you open a J-Web interface session using HTTPS, enter a username and a
password, and then click the Login button, the J-Web interface takes 20 seconds longer
to launch and load the Dashboard page than it does if you use HTTP. PR549934
•
When the J-Web interface is launched using HTTPS, the time shown in the View Events
page (Monitor >Events And Alarms > View Events) differs from the actual time in the
switch. As a workaround, set the correct time in the box after the J-Web interface is
launched. PR558556
Layer 2 Features
•
In a high-scale VPLS configuration, modification of a tunnel interface through a restart
or reconfiguration may cause the packet processing engine to access an invalid interface,
resulting in minor packet loss and logging of packet processing engine traps. Existing
traffic flows on the packet forwarding engine (PFE) are not affected. The router recovers
quickly and normal operation resumes with the new configuration. PR976972
MPLS
114
•
Given a Point-to-Multipoint branch LSP, the value of
jnxMplsTeP2mpTunnelTotalUpTime is reported incorrectly after a new instance of
the branch LSP is re-signaled at the ingress. PR543855
•
When a firewall filter is set on Bidirectional Forwarding Detection (BFD) remote side
egress direction to block the incoming packet in local router point of view , and then
after the firewall filter is deleted, the BFD session might stuck in "Init" state and the
remote state is "Down". PR860951
•
IPv6 traceroute may not show some hops for scenarios where 1) Two LSPs are involved.
2) INET6 Shortcuts are enabled. In such scenarios, hops that are egress for one LSP
and ingress for the next LSP in the traceroute do not show up. This was a software
issue with icmp error handling for packets with ipv6 payload having a ttl of 1. PR899283
•
If 'edit->protocols->mpls->traffic-engineering' knob is configured, then the user cannot
downgrade from a 14.2 release to a pre-14.2 release. In order to downgrade, the user
is required to delete the "traffic-engineering? stanza and re-configure it after
downgrade. PR961717
•
The traffic loss occurs after link up as the old path used for LDP P2MP LSP is not
loop-free. So the traffic loss occurs till the new LDP P2MP branch is established on
Copyright © 2016, Juniper Networks, Inc.
Known Issues
the new best path with mLDP signaling. This is caveat for LDP P2MP make before
break. It works only if the old path is not torn down due to IGP route changes. This can
be solved by using mLDP over RSVP tunneling feature. PR1017032
•
Execution of "clear ldp neighbor all" command may end up with error "error: timeout
communicating with routing daemon" and cause task scheduler slip in a scaled LDP
setup. Traffic loss will be observed. PR1092532
•
These benign error messages can occur when bringing up new interfaces or line cards
and can be ignored. The JUNOS code will be cleaned up to remove these message in
later code. PR1136033
Network Management and Monitoring
•
In rare cases, when the mib2d process attempts connection with the snmpd process
and there are pending requests waiting to be finished, the mib2d process might crash
and the CPU utilization is high around the same time as the crash happens. PR1076643
•
Eventd uses event library for Signal handling. This core dump is due to a race-condition
/ synchronization issue in event library while handling signals. Event library is not signal
safe and thus it is vulnerable to such issues. Eventd handles different kinds of Signals
(Through Signal Handlers) - SIGHUP (On Commit), - SIGTERM (On killing eventd) SIGCHLD (On termination of event script execution) - SIGUSR1 & SIGUSR2 (on log
rotation) If one signal handler is preempted by another signal-handler, then it can mess
up WaitList structures (and this can cause core-dump). This can happen when eventd
received a new signal, when it was processing another signal. This situation may not
happen every-time and hence we see this core-dump rarely. PR1122877
Platform and Infrastructure
•
Adaptive load-balance functionality is only supported for unicast traffic. If the aggregate
bundle contains logical interfaces for bridge or vpls domains, flooded traffic might get
dropped. PR821237
•
CLI command 'show route forwarding-table' would only display <= 16 ecmp paths
when CBF is used. PR832999
•
The audit daemon (auditd) is the daemon which handles system accounting events
and tries to send them out to configured RADIUS servers. If there is any problem in
sending these accounting records to RADIUS (In this case RADIUS servers is unreachable
or disconnecting frequently), auditd will spend more time on each accounting record
because of the retries, and during this time if there are many accounting events, all
those records will be in queue. And at one point of time, queue exceeds its limit and
hence auditd crashes. PR863697
•
When there is huge logical interface (IFL) scaling on AE (500 or more) with more than
32 member links and when all FPCs are restarted one by one, followed by member link
addition to the link aggregation group (LAG), the state dependency evaluation in the
kernel will take a long time given the scale involved, causing the FPCs not getting all
the states from the Routing Engine (RE). This is a pretty uncommon sequence of
events/conditions to happen and the likelihood of this happening in the field is very
remote. PR938592
Copyright © 2016, Juniper Networks, Inc.
115
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
A defect in L3VPN Make Before Break code was resulting in freeing memory
corresponding to old nexthops which is being used by egress PFE. This was resulting
in memory corruption. PR971821
•
In the dual REs scenario, backup RE doesn't sync up the configuration change while
deleting inactivated interface from the master. So after the operation, the inactivated
interface still exists on the backup RE. PR991081
•
The overhead values need to be represented with 8 bits to cover the range "-120..124",
but the microcode is only using the last 7 bits. PR1020446
•
rate-limit value does not match between RE and pfe PR1023809
•
Under very rare situations, packet forwarding engines (PFE) on the following linecards,
as well as the compact MX80/40/10/5 series, may stop forwarding transit traffic: 16x10GE MPC - MPC1, MPC2 This occurs due to a software defect that slowly leaks
the resources necessary for packet forwarding. Interfaces handled by the PFE under
duress may exhibit incrementing 'Resource errors' in consecutive output of 'show
interfaces extensive'. A PFE reboot via the associated linecard or chassis reload is
required to correct the condition. PR1058197
•
On MX Series router with frame-relay (FR) CCC to connect FR passport devices. If
some of the FR circuits carry traffic without any valid FR encapsulations, the MX Series
based Packet Forwarding Engine drops those frames. PR1059992
•
When deleting some uncommitted configuration on active RE, backup RE RPD process
restart due to "Unable to proceed with commit processing due to SIGHUP not received.
Restarting to recover" PR1075089
Routing Protocols
•
BFD triggered local-repair(RLI9007) not initiating immediately on receiving BFD DOWN
packet when the peer has detected the BFD session as down through control expiry.
PR825283
•
The multicast nexthop (show multicast nexthop) shown for Master and Backup RE
for the same flow could be different if the nexthop is hierarchy MCNH. When doing
NSR switch, however, there is no traffic loss caused by this show difference. PR847586
•
When a new bidirectional RP is configured after the RPF to the RP has been resolved,
PIM won't receive a RPF change event. Hence, the RPF interface won't be added to
the multicast route incoming interface list. The traffic forwarding might be affected.
PR939823
116
•
In BGP scenario with IPv4 and IPv6 neighbors mixed in the same group, if all of the
IPv4 peers flaps but none of the IPv6 peers flaps, a timing issue might happen that one
of the IPv4 peers comes up before inet.0 RIB is cleaned up, as a result, the routing
protocol daemon (rpd) crash will be seen. PR986272
•
Junos exhibits two different next-hop advertisement behaviors for MP_REACH_NLRI
on a multi-hop eBGP session, based on whether its loopback peering or physical
interface peering. When the routers are peering on their loopback, only the Global IP
of the interface (lo0) is advertised where as when the routers are peering through the
Copyright © 2016, Juniper Networks, Inc.
Known Issues
physical interface, both Global and Link-local address are advertised as the NHs.
PR1115097
Services Applications
•
The SIP ALG does not recognize or translate the rare 'rtcp' attribute in the SDP payload,
as a consequence non sequential RTP and RTCP ports are not supported. The RTP
flow will be unaffected, not so for the RTCP control flow. PR880738
•
Performance degradation of 8% is observed on the maximum packet per second
supported of jflow records exported. PR949965
•
Performance degradation of 8% is observed on the maximum packet per second
supported of jflow records exported. PR950101
•
When transferring large FTP file, the server might send packets with incorrect layer 4
checksum. If inline NAT service is enabled on the router, it might transit the packets to
client instead of dropping it, which eventually causes the client FTP time out. PR972402
•
In the NAT environment, the jnxNatSrcPoolName OID is not implemented in
jnxSrcNatStatsTable. PR1039112
User Interface and Configuration
•
Selecting the Monitor port for any port in the Chassis Viewer page takes the user to
the common Port Monitoring page instead of the corresponding Monitoring page of
the selected port. PR446890
•
On the J-Web interface, Configure > Routing> OSPF> Add> Interface Tab is showing
only the following three interfaces by default: - pfh-0/0/0.16383 - lo0.0 - lo0.16385
To overcome this issue and to configure the desired interfaces to associated ospf
area-range, perform the following operation on the CLI: - set protocols ospf area 10.1.2.5
area-range 12.25.0.0/16 - set protocols ospf area 10.1.2.5 interface fe-0/3/1 PR814171
•
On HTTPS service J-web is not launching the chassis viewer page at Internet Explorer
7. PR819717
•
On configure->clitools->point and click->system->advanced->deletion of saved core
context on "No" option is not happening at jweb. PR888714
•
When entering the "restart r" incomplete command in the CLI, the command "restart
routing" is executed. It should throw an error like "error: invalid daemon: r". PR1075746
VPNs
•
(Refer to release note of PR 535844) Future releases of Junos OS will modify the
default BGP extended community value used for MVPN IPv4 VRF Route Import
(RT-Import) to the IANA-standardized value. Thus, default behavior will change such
that the behavior of the configuration 'mvpn-iana-rt-import' will become the default
and the 'mvpn-iana-rt-import' configuration will be depricated. PR890084
•
In a multi-homed source topology in NG-MVPN (applicable to both inter-AS and
intra-AS scenario), there are two problems: The first problem is Multicast (S, G)
signaling doesn't follow RPF. When the routing table (mvpninstancename.inet0) has
Copyright © 2016, Juniper Networks, Inc.
117
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
two routes, due to the policy configuration, the best route to the source is via the MPLS
core, but Multicast (S, G) PIM join and NG-MVPN Type 7 both point to inactive route
via local BGP peer. The second problem is when "clear pim join instance NG" is entered,
the multicast forwarding entries are wiped out. PR1099720
Related
Documentation
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Resolved Issues on page 118
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Resolved Issues
This section lists the issues fixed in the Junos OS main release and the maintenance
releases.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
Resolved Issues: 14.2R6 on page 118
•
Resolved Issues: 14.2R5 on page 134
•
Resolved Issues: 14.2R4 on page 155
•
Resolved Issues: 14.2R3 on page 171
•
Resolved Issues: 14.2R2 on page 188
Resolved Issues: 14.2R6
118
•
Class of Service (CoS) on page 119
•
Forwarding and Sampling on page 119
•
General Routing on page 119
•
High Availability (HA) and Resiliency on page 125
•
Infrastructure on page 125
•
Interfaces and Chassis on page 125
•
Layer 2 Features on page 127
•
Layer 2 Ethernet Services on page 127
•
MPLS on page 128
•
Network Management and Monitoring on page 129
•
Platform and Infrastructure on page 129
•
Routing Protocols on page 131
•
Routing Policy and Firewall Filters on page 133
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Services Applications on page 133
•
User Interface and Configuration on page 133
•
VPNs on page 133
Class of Service (CoS)
•
This PR does optimization in AE SNMP handling. If all the links in an AE bundle go down,
then any COS SNMP query for this AE IFD/IFL will return cached values PR1140440
•
On MX104 platform, when applying the "rate-limit" and the "buffer-size" on the logical
tunnel (lt-) interface on the missing MIC (not inserted on MPC), commit failure with
error message would occur. As a workaround, this issue could be avoided by applying
the "rate-limit and "buffer-size" on inserted MIC, then commit. PR1142182
Forwarding and Sampling
•
On MX80 and MX104 platform, applying firewall filter with Trio specific match condition
will raise warning message below. Filter <filter_name> is Trio specific; will not get
installed on DPCs for interface <interface_name>. This warning message is needed
for the other modular type MX platform since it can have DPC and MPC mixed. But the
message is not needed for MX80 and MX104 platform since they only have Trio based
PFE. Although the warning message tells that the relevant firewall filter is not installed,
the firewall filter is correctly installed into PFE. Thus, user can ignore the message in
case the warning message is logged on MX80 and MX104 platform. PR1138220
•
For Junos OS release 14.1R1 and above, when a broadcast packet is sent in a scenario
of Integrated routing and bridging (IRB) over Virtual Tunnel End Point (VTEP) over IRB,
the packet is getting dropped in kernel as it was looping due to a software issue. The
error log message "if_pfe_vtep_ttp_output: if_pfe_ttp_output failed with error 50" is
observed when issue occurs. PR1145358
General Routing
•
On an MX Virtual Chassis platform, when we restart one or both of the standby Routing
Engines (REs), the log message "ksyncd_select_control_plane_proto:
rhost_sysctlbyname_get: No such file or directory" might be observed as the ksyncd
daemon attempts to select a communication protocol (UDP/TCP). After several tries,
it will fall back to TCP and proceed as normal. PR945925
•
In MX Virtual Chassis (MX-VC) environment, the private local nexthops and routes
pointing to private local nexthops are sent to PFE from master RE and not sent to slave
RE, then an RE switchover happens. Now as the new master RE does not know about
such nexthops and routes, they are not cleaned up. When a nexthop with same index
is added on new master RE and sent to PFE, the PFE might crash due to a stale nexthop
exist. PR951420
•
On MX platform, MPC may crash when bringing up the 100-Gigabit Ethernet MIC with
CFP2 (model number: MIC6-100G-CFP2) if initialization failure occurs (e.g. when
bringing up the MIC6 which has hardware issue). PR1037661
•
There is a remote loop back feature in 802.3ah standard, where one end can put remote
end into remote-loopback mode by sending enable loopback control lfm PDU. In
remote loopback, all incoming packets (except lfm packets) are sent back on wire as
Copyright © 2016, Juniper Networks, Inc.
119
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
it is. Transmit or receive of lfm packets should not be affected when an interface is in
remote loopback mode. on VMX platform when we configure the lfm remote-loopback
we run into problem state, In problem state we will see that LFM packets sent from
node which is in loopback state is not reaching the peer end hence we will not see the
remote entity information for the "run show oam ethernet link-fault-management"
command on peer router. PR1046423
120
•
On all routing platforms M/MX/T/PTX with BGP configured to carry flow-specification
route, in case of deleting a filter term and policer, then add the same term and policer
back (it usually happens in race condition when adding/deleting/adding the flow
routes), since confirmation from dfwd for the deleting policer might not be received
before attempting to add the same policer, the rpd would skip sending an add operation
for it to dfwd. As a result, when the filter term is sent to dfwd and tell it to attach to
the policer, dfwd had already deleted the policer, and since rpd skipped re-adding it,
dfwd will reject the attach filter with policer not found error and rpd will crash
correspondingly. PR1052887
•
When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP
routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP
routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the
rpd process might crash. PR1063796
•
During GRES switchover, chassisd reconstructs the fabric plane state from FPC during
plane online operation. If FPCs report inconsistent state where number of active-active
planes exceed the max allowed numbers (4, 4 is related to internal plane state),
chassisd will crash continuously since the condition does not correct itself. However,
the events lead to the condition is unknown yet. This fix puts in a work-around to prevent
the continuous chassid crash at reconnect expire so that if the condition is detected
(FPCs report inconsistent state), all planes are bounced by offline all planes first, and
follow with online of the planes. Given the FPCs are all online already, the bouncing of
the planes should take reasonable time. PR1070116
•
PCE created LSPs will have same preference as locally configured LSPs. However
preference can be changed via template configuration. PR1075559
•
If NSR (Nonstop Routing) is enabled and a TCP session is terminated while there is
still data in the socket pending transmission, the MBUF (Kernel Memory Buffer) used
to store this data might not get deallocated properly. In order to hit this issue the TCP
session must use NSR active socket replication. If the system runs low on MBUF memory
the kernel will automatically throttle down memory allocation on low priority
applications and ultimately if there is no MBUF left, the system could become
unresponsive due to its inability to serve I/O requests. PR1098001
•
Fragmenting a special host outbound IP packet with invalid IP header length (IP header
length is greater than actual memory buffer packet header length), can trigger NULL
mbuf accessing and dereferencing, which may lead to a kernel panic. PR1102044
•
After executing the CLI commands "show route detail" or "show route extensive", the
routing protocol process (RPD) might get stuck into an infinite loop and might stop
responding to any events such as CLI commands, protocol keepalives, etc. This would
result in a time out of all protocol adjacencies and a high CPU utilization by RPD might
be seen on the device (over 90% used by RPD). In some cases the memory which is
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
used to store the command output might not be freed during executions, which might
lead to an RPD restart because of memory exhaustion (RLIMIT exceeded). PR1104090
•
On MX240/480/960 Series router with MS-DPC, customer running BGP over IPSec.
This BGP session has a BFD session tied to it. The BGP session is up but the BFD session
remains in INIT state. The issue might be seen with any service configured with multihop
BFD enabled. Traffic forwarding will not be affected. PR1109660
•
This issue is a regression defect introduced in Junos OS Release 11.4R11, 12.1R10, 12.2R8,
12.3R6, 13.2R4, 13.3R2, 14.1R1. After upgrading to those releases containing the original
fix, when there is no export policy configured for forwarding table to select a specific
LSP, whenever routes are resolved over RSVP (for example, due to aggressive
auto-bandwidth), resolver will spend considerable amount of time on resolver tree,
which contributes to base line increase in rpd/RE CPU. PR1110854
•
Right now this fix is available from 14.2R6 onwards. On 14.2R5 or older images MSRPC
gates once opened would never gets deleted. From 14.2R6 onwards, MSRPC gates are
opened for 60 mins no matter whether expected packet hits gate or not. After 60
minutes gates are deleted by timer. PR1112520
•
On a busy MX Series Virtual Chassis platform, for example, with 100k subscribers and
16k subscribers concurrent login/logout, the ksyncd process might crash on Virtual
Chassis backup Routing Engines (REs) after a local or global graceful Routing Engine
switchover (GRES). This issue has no service impact. PR1115922
•
On TX/TXP platform, when an LCC hit overtemp situation, it might go offline abruptly
without notify SFC and other LCCs, which might cause traffic loss or performance
degradation. Now with the fix, the overtemp situation on LCC is handled gracefully.
PR1116942
•
On M/MX platform, the 10G Tunable SFP/SFP+ can not be tuned in Junos release
15.1R2. PR1117242
•
On MX series routers containing multiple PFEs (Packet Forwarding Engines) such as
MX240/MX480/MX960/MX2010/MX2020, with either MPC3E/MPC4E/MPC5E/MPC6E
cards,if the routers have GRE decap, then certain packet sizes coming via these
aforementioned line cards, at very high rate can cause these line cards to exhibit a
lockup, and one or more of their PFEs corrupt traffic towards the router fabric. PR1117665
•
On MX platform, in rare condition, if removing or deactivating "member-interfaces"
configured for an aggregated Multiservices (AMS) bundle (only officially supported
on MS-MPC/MS-MIC), for example, using CLI command "deactivate interfaces ams0
load-balancing-options member-interface mams-7/1/0", all the Trio-based FPCs and
the MS-MPC/MS-MIC may crash. As a workaround, to avoid the issue, below is the
recommended procedures to change AMS bundle size, 1. Offline member PICs 2. Change
AMS configuration 3. Online member PICs PR1119092
•
On MS-MPC equipped MX platform, during the "three-way handshake" process, when
receiving ACKs (e.g. after sending SYN and receiving SYN/ACK) with window size 0
(as reported, it is set to 0 by TCP client when using some proprietary protocol), the
ACKs would be incorrectly dropped by the line card due to failure in TCP check. This
issue could be avoided by preventing software from dropping packets that fail in the
Copyright © 2016, Juniper Networks, Inc.
121
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
check, for example, by CLI command below, re# set interfaces ms-3/0/0
services-options ignore-errors tcp PR1120079
122
•
On MX platform, the MS-MPC crash may occur. The exact trigger of the issue is
unknown, normally, this issue may happen over long hours (e.g. within a week) of traffic
run (e.g. running HTTP/HTTPS/DNS/RTSP/TFP/FTP traffic profile). PR1124466
•
With BGP configured on CE-faced interfaces (in VRFs), doing 'show route' frequently
may cause rpd to slowly leak memory. The leak rate will be one memory block of the
size necessary to hold the instance name of the routing instance for a BGP neighbor.
If the rpd process memory exhausted, the rpd process might crash, and the routing
protocols are impacted and traffic disruption will be seen due to loss of routing
information. You can check rpd memory usage with "show task memory brief"
command. PR1124923
•
Right now this fix is available from 14.2R6 onwards. On 14.2R5 or older images SUN
RPC gates once opened would never gets deleted. From 14.2R6 onwards, SUN RPC
gates are opened for 60 mins no matter whether expected packet hits gate or not.
After 60 minutes gates are deleted by timer. PR1125690
•
In EVPN scenario, the EVPN route table between the master RE and backup RE would
be different (unused garbage routes will appear) once RE switchover (e.g. by rebooting
the "old" master RE or performing graceful routing engines switchover) is performed,
which may cause kernel crash on the new master RE in some cases. PR1126195
•
When Junos devices use Link Layer Discovery (LLDP) Protocol, the command 'show
lldp neighbors' displays the contents of PortID Type, Length, and Value (TLV) received
from the peer in the field 'Port Info', and it could be the neighbor's port identifier or port
description. Junos CLI knob can select which 'interface-name' or 'SNMP ifIndex' to
generate for the PortID TLV, so we do not have any problem as long as two Junos
devices are connected for LLDP, but we might have an interoperability issue if other
vender device which can map the configured 'port description' in the PortID TLV is
used. In such case, Junos displays the neighbor's PortDescription TLV in the 'Port info'
field, and if the peer sets 'port description' whose TLV length is longer than 33
byte(included), Junos is not able to accept the LLDP packets then discards packets
as errors. The PortID TLV is given as : "the port id tlv length = port description field
length + port id subtype(1B)" PR1126680
•
EVPN route attributes like the label and ethernet segment identifier (ESI) may be
missing from EVPN family routes installed by BGP. PR1126770
•
On M320/T320/T640 with FPC 1/2/3 and their enhanced version (-E2/-E), in multicast
scenario and AE interface is within multicast NH (such as, AE interface is the
downstream interface for a multicast flow), egress multicast statistics displays
incorrectly after flapping of AE member links. PR1126956
•
On MX platform, when offlining the line card (possibly, with any of the line cards listed
below), "Major alarm" might be seen due to HSL (link between line card and PFE)
faults. This fault is non-fatal and would not cause service impact. The line cards that
may hit the issue could be seen as below, MS-MPC/MS-MIC MIC-3D-8DS3-E3
MIC-3D-8CHDS3-E3-B MIC-3D-4OC3OC12-1OC48 MIC-3D-8OC3OC12-4OC48
MIC-3D-4CHOC3-2CHOC12 MIC-3D-8CHOC3-4CHOC12 MIC-3D-1OC192-XFP
MIC-3D-1CHOC48 PR1128592
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
In current Juniper implementation, the IPv6 multicast Router Advertisement timer is
not uniformly distributed value between MinRtrAdvInterval and MaxRtrAdvInterval as
described in RFC 4861. PR1130329
•
When software encounters an error configuring the optics type into the VSC8248 PHY
retimer component of an MX MIC/PIC (typically done on SFP+ module plugin), this
could lead to 100% FPC CPU utilization indefinitely. MPCs and MICs that are potentially
affected are: MPC3 + 10x10GE SFPP MIC MPC4 32XGE MPC4 2CGE+8XGE (10G
interfaces only) MPC6 + 24x10GE (non-OTN) SFPP MIC PR1130659
•
On MX with MS-MIC (or possibly, MS-MPC is affected as well), changing configuration
of sampling input parameters, such as "rate" under forwarding-options is not reflected
without restarting the line card. PR1131227
•
When using Point-to-Point Tunneling Protocol (PPTP) Application Layer Gateways
(ALG) on MS-MPC/MS-MIC, if running scaled number of PPTP sessions control and
data sessions (e.g. 1M sessions) for long hours (e.g. more than 8 hours), when the traffic
is stopped, the "Bytes used" field of the output of CLI command "show services
service-sets summary" will show a randomly large value due to memory issue. PR1131605
•
On Trio based line card, multiple modifications of firewall filter might cause lookup
chip error and traffic blackhole, following jnh_free error messages could help to identify
this issue: messages: fpc1 jnh_free(10212): ERROR [FW/3]:1 Paddr 0x006566a9, addr
0x2566a9, part_type 0call_stack 0x40497574 0x418ffa84 0x41900028 0x418ecf94
0x41861690. PR1131828
•
CLI output of "clear services sessions" gives an impression to the user that session is
marked for deletion in case of delayed delete but the XML output "clear services
sessions|display xml"of the above command says "session removed". Ideally both
should convey the same message to the user. The changes have been made to make
sure CLI and XML information given to the user in sync. PR1132006
•
When customers do changes under "protocol router-advertisement interface X" (such
as changing timers etc), they expect that commit would trigger an new
router-advertisement being sent out to notify hosts about configuration changes.
However it does not seem to be a case unfortunately. It makes the router information
to expire on hosts and causes obvious loss of connectivity for the hosts. PR1132345
•
On MX platform with non-Q MPC (for example, MPC2-3D) or Q-MPC with
enhanced-queueing off, when traffic has to egress on any one of the dynamic PPPoE
(pp0), IP-DEMUX (demux0) and VLAN-DEMUX (demux0) IFLs, the queue mapping
might get wrong. The traffic forwarding might be affected. PR1135862
•
MXVC-Same subnet VC-heartbeat polling failed to recover PR1136119
•
On MS-MIC, TCP session Up/Down causes JSERVICES_NAT_* and
JSERVICES_SESSION_* messages though severity level "none" is configured for services
PR1137596
•
MIC-3D-16CHE1-T1-CE only supports 4 queues by default due to the incorrect setting
in code, this is a very minor change to make MIC-3D-16CHE1-T1-CE support 8 queues
by default. PR1138270
Copyright © 2016, Juniper Networks, Inc.
123
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
JNH periodically attempts to recover memory no longer in use. Recently when Firewall
address space was expanded to 16M, a side effect was triggered -- memory recovery
was extended to 16M as well. On the Hercules line card, Firewall does not use a small
block of IDMEM, causing JNH to attempt the return of the unused memory. There is no
mechanism for recovery of IDMEM, therefore, this message is displayed. Excepting the
syslog impact, there is no further effect on the line card. PR1140021
•
In Junos Fusion environment, if there are power failures or power not connected issues
on satellite device (SD), the "jnxPowerSupplyFailure" traps could not be generated
by aggregation device (AD) due to lack of support. For example, in case there are 2
Power Entry Modules (PEMs) inserted on the SD while one PEM is not powered on, the
AD (e.g. MX) would not generate the trap for this PEM. PR1140097
•
When multicast-only fast reroute (MoFRR) is enabled in PIM or multipoint LDP domain,
memory leak will be observed on generation of the multicast FRR next-hops. The leak
rate is 8-byte for IPv4 and 12-byte for IPv6 addresses, per FRR next-hop created.
Eventually, the rpd process will run out of memory and crash when it cannot honor
some request for a memory allocation. PR1144385
•
When ARP is trying to receive a nexthop message whose size (for example 73900
bytes) is bigger than its entire socket receive buffer (65536 bytes), the kernel might
crash, and the traffic forwarding might be affected. PR1145920
•
Upon either FPC boot with 100G CFP2 MIC installed or upon 100G CFP2 MIC installation
post FPC boot, if the MIC is unable to initialize correctly, the MPC6E can crash and then
restart. This has only been seen when the MIC has suffered a hardware failure.
PR1148325
124
•
In EVPN environment, when CE MAC address alone gets changed for a MAC+IP entry,
new MAC+IP entry is not getting reflected in EVPN database and the old entry still
exists on PE router. PR1149340
•
When a routing instance is configured with "routing-instances <instance-name>
routing-options localized-fib" then VPN localization may fail, causing all routes for the
affected routing instance to be installed on all PFEs. PR1149840
•
Commit error after attempting to delete all guaranteed rates on all
traffic-control-profiles associated with demux0 [edit] [email protected]_09# commit
re0: [edit class-of-service interfaces] 'demux0' IFL excess rate not allowed on interface
(demux0), please specify guaranteed rate on at least one IFL error: configuration
check-out failed PR1150156
•
When using type 5 FPC on T4000 platform, traffic go out of the interface where
"source-class-usage output" is configured will be dropped if the Source class usage
(SCU) or Destination Class Usage (DCU) policy configuration is missing. This issue is
caused by incomplete configuration so, to avoid the issue, please make the configuration
complete (e.g. with "source-class-usage output" and SCU policy). PR1151503
•
From Junos OS release 14.2 with "exclude-hostname" configuration, hostname is not
excluded from the messages before forwarding. This is a minor case, no other service
impact. PR1152254
•
Routers using inline layer 2 services may experience fabric degradation and FPC restart.
This problem is amplified by fragmented and out of order packets. This log entry may
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
be seen during the error state: Host Loopback:HOST LOOPBACK WEDGE DETECTED
IN PATH ID 0 PR1153750
•
In the TXP environment, the Line-Card Chassis (LCC) Switch Interface Board (SIB)
status is not right when execute command "[email protected]> show chassis environment",
their status are Absent, but no alarms. This is a minor issue, it does not affect business.
PR1156841
•
On MX Series routers with enhanced queuing DPCs, there is a memory leak whenever
doing SNMP walk to any of COS related OID's or issue the command "show interfaces
interface-set queue <interface-set>”. PR1160642
High Availability (HA) and Resiliency
•
With NSR enabled on multiple RE system, when dynamic GRE tunnel is configured,
performing RE switchover might causing rpd crash repeatedly on backup RE. PR1130203
Infrastructure
•
The Remote NFS Server process (nfsd) is not terminated on the new backup Routing
Engine (RE) after RE switchover. As a result, it spawns a new one upon RE switchover
until running out of memory. PR1129631
Interfaces and Chassis
•
jnxBoxDescr is reworded for MXVC to replace the platform type with a more general
representation that replaces the specific member platform type with "Virtual Chassis".
Old virtual chassis text example: jnxBoxDescr.0 = member0 Juniper MX240 Internet
Backbone Router New virtual chassis text example: jnxBoxDescr.0 = member0 Juniper
MX Virtual Chassis Internet Backbone Router NOTE: The MIB design for jnxBoxAnatomy
"top-level" chassis information works properly for a standalone chassis, but doesn't
fully represent virtual chassis multi-member configurations because it is capable of
providing information for only one physical chassis. (The remainder of the
jnxBoxAnatomy MIB "containers" properly support the inventory of a multi-member
configuration.) MX virtual chassis provides another MIB, jnxVirtualChassisMemberTable,
to supply the equivalent "top-level" information. PR1024660
•
MS-DPC might crash when allocating chain-composite nexthop in enhanced LAG
scenario. PR1058699
•
Link Up/Down SNMP traps for AE member links might not be generated, but the SNMP
traps for the AE bundle works well. PR1067011
•
When DHCP subscribers are terminated at specific routing-instances and the interface
stack is IP demux over vlan-subinterface over AE interface, there might be a memory
leak in kernel AE iffamily when subscribers login/logout. PR1097824
•
The following CLI knob needs to be used for CFM session to work. "set chassis
aggregated-devices disable-lag-enhanced". Ehanced-lag is enabled by default in the
system when the system is configured with enhanced-ip. CFM is not supported with
enhanced-lag at present. PR1116826
•
If two redundant logical tunnels (rlt) sub-interfaces are configured in a same subnet
and in a same routing-instance, a sub-interface will be down (this is expected), but if
Copyright © 2016, Juniper Networks, Inc.
125
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
the sub-interface is removed from the routing-instance later, after disable and enable
the rlt interface, a sub-interface might remain in down state unless removing
configuration of rlt interface and then rollback. PR1127200
126
•
MXVC specific behavior for SNMP walk of jnxOperating* containers was divergent
from physical MX. Returned to vergence. PR1136414
•
Due to movement of SNMP stats model from synchronous requests to asynchronous
requests in Junos OS release 13.3R1, the IQ2/IQ2E PIC, which has limited memory and
CPU power, can not handle scaled SNMP polling at high rate (e.g., a burst of 4800
SNMP requests). This issue comes with high rate SNMP stats polling for IQ2/IQ2E
interfaces or Aggregated Ethernet (AE) interface with IQ2/IQ2E as member links. These
memory failures can cause IQ2/IQ2E PIC reboot because keep alive messages will also
not get memory. PR1136702
•
On MX platform, the "Max Power Consumption" of MPC Type 1 3D (model number:
MX-MPC1-3D) would exceed the default value due to software issue. For example, the
value might be shown as 368 Watts instead of 239 Watts when "max ambient
temperature" is 55 degree Celsius. PR1137925
•
When Micro Bidirectional Forwarding Detection (BFD) sessions are configured for link
aggregation group (LAG), the device control process (DCD) acts as the client to the
micro BFD session. In order to monitor the connection between client (DCD) and
server(BFD), client needs to exchange keep alive hello packets with the server. To send
hello packets, DCD needs to move out of IDLE phase to CONFIG_BFD phase which is
the reason for below log messages: dcd.c:585 dcd_new_phase_if_idle() INFO : Current
phase is IDLE, going to phase CONFIG_BFD usage.c:75 dcd_trace_times() INFO : Phase
Usage for IDLE : user 0.001 s, sys 0.000 s, wall 60.019 s dcd.c:717 dcd_new_phase()
INFO : New phase is CONFIG_BFD usage.c:75 dcd_trace_times() INFO : Phase Usage
for CONFIG_BFD : user 0.000 s, sys 0.000 s, wall 0.000 s dcd.c:717 dcd_new_phase()
INFO : New phase is IDLE There is no functionality impact, however these messages
may flood the logs. As a workaround, we can filter out these messages from being
written to the log file according to this KB article:
http://kb.juniper.net/InfoCenter/KB9382 PR1144093
•
On OAM maintenance domain intermediate Point (MIP), the connectivity fault
management (CFM) will not be enabled on L2VPN interface if it is configured after
L2VPN is up. PR1145001
•
The alarm "CB 0 ESW PFE Some Ports Failed " was triggered by the difference
"rcb_handle_esw_port_status Some Port Lost Connection online_mask" between CB0
and CB1, But the issued mask-bit was directed to an none-existed FEB. PR1148869
•
With Junos OS release 14.2R1 to 14.2R5, for an Multichassis link aggregation group
(MC-LAG) running in active-standby mode, when two MC-LAG peers are connected
to a specific vender's device (e.g., NEC QX switch), after the configured MC-AE active
node is rebooted, both MC-AE member links will become "Collecting distributing"
(Active) status for LACP. Depends on topology, there might be a loop and causing
broadcast storm. PR1158444
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Layer 2 Features
•
When AE is core facing ifl in ldp-mesh vpls instance with local-switching in it, the traffic
is looped back. PR1138842
•
In a VPLS scenario, when "$junos-underlying-interface-unit" is configured in
"dynamic-profiles" hierarchy, which is then implemented in a routing-instance. The
upgrade/commit will fail with the following error message, Parse of the dynamic profile
(<dynamic_profile_name>) for the interface: $junos-interface-ifd-name and unit:
$junos-underlying-interface-unit failed! PR1147990
•
For router equipped with following line cards: T4000-FPC5-3D MX-MPC3E-3D
MPC4E-3D-32XGE-SFPP MPC4E-3D-2CGE-8XGE MPC5E-40G10G MPC5EQ-40G10G
MPC6E MX2K-MPC6E If the router is working as VPLS PE, due to MAC aging every 5
minutes, the VPLS unicast traffic is flooded as unknown unicast every 5 minutes.
PR1148971
Layer 2 Ethernet Services
•
There is a bug in code of handling the redistribution of PPM (periodic packet
management) Transmit and Adjacency entries for LACP, when the Interface entry is
in pending distribution state. This issue might cause ppmd crash after graceful RE
switchover. PR1116741
•
For RE generated packet with VLAN tag, if the outgoing interface is an LT interface,
the VLAN tag will not be removed even the LT interface is configured with untagged
encapsulation. PR1118540
•
In the DHCPv4 or DHCPv6 relay environment with large scaled environment (in this
case, 50-60K subscribers), and the system is under stress (many simultaneous
operations). The subscribers might get stuck in RELEASE state with large negative
lease time. PR1125189
•
Input/Output pps/bps statistics might not be zero after a member link of AE interface
with distributed ppmd was down in M320/T-Series(GIMLET/STOLI based FPC)
PR1132562
•
When the LACP hold timer config is added and LACP is getting activated for the first
time on the parent interface, the lacpd process might crash. PR1135187
•
When a power supply is failed, the Power Supply failed alarm is generated every 30
minutes. The expected interval is every 60 minutes. This is a minor issue, no other
service impact. PR1144795
•
The "Node ID" information is not shown on MX platform when traceoption flag "pdu"
is configured to trace Ethernet ring protection switching (ERPS) PDU reception and
transmission. PR1157219
Copyright © 2016, Juniper Networks, Inc.
127
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MPLS
•
With egress protection configured for Layer 3 VPN services to protect the services from
egress PE node failure in a scenario where the CE site is multihomed with more than
one PE router, when the egress-protection is un-configured, the egress-protection
route cleanup is not handled properly and still point to the indirect composite nexthop
in kernel, but the composite nexthop can be deleted in rpd even the egress protection
route is pointing to the composite nexthop. This is resulting in composite nexthop "File
exists" error when the egress protection is re-enabled and reuse the composite nexthop
(new CNH addition fails as old CNH is still referenced in kernel). PR954154
•
In MPLS scenarios, removing the "family mpls" configuration from an outgoing interface
may cause inet and/or inet6 nexthops associated with that interface to unexpectedly
transit to dead state. Even adding back "family mpls" cannot restore it. PR1067915
•
For advertising IPV6 packets over MPLS GRE tunnel, the IPv6 address gets stuck in
KRT queue. PR1113967
•
If a RSVP LSP has both primary& standby path and link-protection enabled, a /32
bypass route is unhidden when the primary link goes down. This /32 route is supposed
to be made hidden again when primary link comes back up. But in some cases, due to
software defect, this /32 bypass route remains unhidden forever which causes some
issues, for example, BFD session down due to better prefix received from Bypass LSP.
PR1115895
128
•
During interoperation with CISCO device (e.g. CRS) belongs to different IGP area, if
the P2MP LSP ping echo reply message from Cisco device is using interface address
other than loopback/router-id as the source address, the reply message will be dropped
on Junos device. With the fix, Junos device will accept the packets and print them as
'uncorrelated responses'. PR1117166
•
When an PLR is a non-Juniper router, Juniper ingress node might stay on the bypass
tunnel and ignore the CSPF result. PR1138252
•
When a link fails on an RSVP LSP which has link-protection or node-link-protection
configured, the PLR (point of local repair) will initiate a bypass LSP and the RSVP LSP
will be tunneled on this bypass LSP. However, if now the bypass LSP is brought down
because there is a link failure on it, the PLR might only send out session_preemted
PathErr message to the upstream node without sending ResvTear message. Hence
the ingress node does not receive ResvTear message and the RSVP LSP is not
immediately torn down. The RSVP LSP will remain UP for more than 2 minutes until
the RSB (Resv sate block) on the ingress's downstream node gets time out and it sends
ResvTear message to the ingress. PR1140177
•
There is no entropy label for LDP route in scenario of LDP tunneling across a single hop
RSVP LSP with label 0 (explicit-null) used. As workaround, either remove LDP tunneling
or RSVP explicit-null will resolve the issue. PR1142357
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
This issue is related to inter-op between multi vendor scenario. This fix will add
sub-object RRO which will help change of label during FRR active scenario. PR1145627
•
MPLS TED might not select random links to calculate the ERO when OSPF is
overloaded. Instead, only one or two interfaces will be used for all the configured LSPs
originating from the router. PR1147832
Network Management and Monitoring
•
Mib2d cores while trying to re-add a lag child into the internal DB. Since the entry is
already present in the internal DB. Before adding the child link mib2d does a lookup on
the tree, to know if the entry is not already there. However, this lookup returns no results,
since the child link is part of snmp filter-interface configuration. PR1039508
•
LAG MIB tables dot3adAggPortTable, dot3adAggPortDebugTable polling or lag
configuration changes may result in mib2d process core or unexpected values for lag
MIB OIDs. The PR fix will resolve these MIB table issues. PR1060202
•
With Junos OS release 13.3R8/14.1R6/14.1X53-D30/14.2R5/15.1R2/15.1X49-D30 and
above, when we configure fxp0 "master-only" address as source address of snmp
trap, the snmp trap packets are not sent out after Routing Engine (RE) switchover. To
restore this issue, we can use "restart snmp" or "delete/set snmp trap-options". As a
workaround, we can use other addresses for snmp trap source. PR1153722
Platform and Infrastructure
•
Certain combinations of Junos OS CLI commands and arguments have been found to
be exploitable in a way that can allow root access to the operating system. This may
allow any user with permissions to run these CLI commands the ability to achieve
elevated privileges and gain complete control of the device. Please refer to JSA10608
for additional information. PR912707
•
When one of the "deny-commands" is incorrectly defined in the profile of TACACS+
server, all "deny-commands" regexes will be ignored, which leads to an over-permissive
profile without any warning. PR1078238
•
With ECMP-FRR enabled, after rebooting the FPC which hoisting some ECMP links,
the ECMP-FRR might not work. Clear any of BGP sessions (that is the part of ECMP)
could help to clear this issue. PR1101051
•
Junos defines SNMP ifXTable (ifJnxInErrors/ifJnxInL3Incompletes) counter as 64-bit
width, but it worked as 32-bit width counter. It works as 64-bit width counter after the
fix. PR1105266
•
On MX-VC, when traffic with TPID 0x88a8 or 0x9100 is sending over AE interface, the
packets which across VCP links might be dropped on egress VCP PFE due to invalid
fabric token. PR1112752
•
With Junos release 14.2R4, on MX platform acting as the aggregation device (AD) in
Junos fusion solution, when unicast nexthops of extended ports are deleted and added,
the routing chip memory is not freed during the next-hop deletion. Two double words
will be leaked per nexthop deletion. PR1114369
•
Inline 6rd and 6to4 support for XL and XL-XM based platforms. PR1116924
Copyright © 2016, Juniper Networks, Inc.
129
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On Trio based line card, for GRE over IPv6 packet with layer 4 length less than 8 bytes,
it will be discard by reason "L4 len too short". PR1126752
•
For IPv6 packet with "no next header" in Hop-By-Hop header, if the Hop-By-Hop header
length field value is large than 112, the router will drop such packet and log the following
error: PPE PPE HW Fault Trap: Count 105, PC 60ce, 0x60ce: ipv6_input_finished_parsing
LUCHIP(3) PPE_10 Errors lmem addr error PR1130735
•
NTP.org published a security advisory for thirteen vulnerabilities in NTP software on
Oct 21st, 2015. These vulnerabilities may allow remote unauthenticated attackers to
cause Denial(s) of Service(s), disruption of service(s) by modification of time stamps
being issued by the NTP server from malicious NTP crafted packets, including
maliciously crafted NTP authentication packets and disclosure of information. This
can impact DNS services, as well as certificate chains, such as those used in SSL/https
communications and allow attackers to maliciously inject invalid certificates as valid
which clients would accept as valid. Refer to JSA10711 for more information. PR1132181
•
Doing a file copy from a Routing-Engine running Junos OS image to a Routing-Engine
running Junos OS with Upgraded FreeBSD image fails. PR1132682
•
Too many duplicate ACK messages are generated from PFE for TCP control connection
with RE. This could cause: 1. MX-VC DDoS protection violation for VC-control low queue
and makds MXVC split. 2. Cause RE and FPC high CPU utilization. PR1133293
•
With scaled firewall filters attached to interfaces (e.g. 10k+ filters), running "show
configuration" command can cause high CPU of the mgd process. As a workaround,
we can use "show configuration |display set" command to view the config. PR1134117
•
PPE thread timeout trap may cause XM chip wedge, it will not affect MQ based FPC.
PR1136973
130
•
On MX2020, when we remove whole power of a power zone, and then put the power
back to the zone, FANTray LED stays Amber and FANTray LED on craft card stays OFF,
and do not revert to green (FANTray LED) or ON (Craft LED) until we reboot the entire
chassis system or hot swap that FAN tray. For Zone 0(PSM 0 to 8), FAN 1 shows the
above described behavior. For Zone 1(PSM 9 to 17), FAN 3 shows the above described
behavior. PR1138209
•
When the cli command "show pfe statistics exceptions | match reject" is executed
CPROD thread in the PFE may hog the CPU and result in FPC crash. PR1142823
•
In certain affected JUNOS releases, executing "nhinfo -d" shell command might trigger
a kernel panic. This is caused by insufficient buffer space in the routing socket requested
by the "nhinfo" utility. PR1148220
•
When the NTP server address is configured in VRF table and reachable from inet.0 by
static configuration (for example, by configuring static/route/next-table/VRF.inet.0),
and NTP source-address is configured, the ntpd (the Network Time Protocol daemon
running on NTP client) might pick the wrong source-address instead the configured
source-address. As a result, NTP server cannot reply the NTP packet back. PR1150005
•
During the ISSU upgrade, line cards may crash causing service impact. When the lines
cards come up, there may be a programming issue as a secondary impact and some
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
IFLs may not pass traffic. Affected line cards need to be rebooted to recover from this
condition. PR1152048
•
On MX Series routers with Junos OS release 14.2R5-S1, when we specify a multiservice
(ms-) interface to add a timestamp to Real-time Performance Monitor (RPM) probe
messages, it will cause the mspmand process crash and the MS-MPC/MS-MIC keep
crashing. As a workaround, we should configure RPM to perform timestamping either
on the Routing Engine (RE based RPM) or on an installed MPC PFE (Inline-RPM).
PR1152785
•
Fixed an issue with Inline Jflow where the Observation Domain field in exported IPFIX
datagrams were always using the value attributed for LU0 in MPCs with multiple LUs
per forwarding-engine. PR1152854
•
Fixed an issue on where Trio cards could crash while programming a firewall filter
containing flexible-match-mask. PR1157759
Routing Protocols
•
When a BGP session supports multiple address families, the inactive route of some of
the address families might not be flushed correctly, leading to wrong behaviors for
some of the features which need to advertise inactive routes(e.g. advertise-inactive,
advertise-external, optimal-route-reflection, etc). PR1097297
•
IGMPv2 working in v2/v1 compatibility mode does not ignore v2 Leave messages
received on a bridge-domain's L2 member interface. Moreover, an IGMP snooping
membership entry for the respective group at this L2 member interface will be timed
out immediately upon IGMPv2 Leave reception, even when there are some other active
IGMP hosts attached to this L2 member interface. It might breaks multicast forwarding
for this L2 member interface. PR1112354
•
When two (or more) route target communities of MP-BGP route match to two (or
more) route target communities in VRF import policy of a RI duplicate routing entries
might be installed in the RI. In the output of 'show route table <RI-name>.inet.0 detail'
two identical routing entries appear with one being marked as 'Inactive reason: Not
Best in its group - No difference'. When such duplicate routing information is to be
deleted, rpd process process will crash. PR1113319
•
There may be stale bfd session after channging physical terface mtu, it may also cause
bfd session flap continuous or stay in down state. PR1116666
•
During many types of configuration changes, especially including import policy, BGP
has the need to re-evaluate the routes it has learned from peers impacted by the
configuration change. This re-evaluation involves re-running import policy to see if
there is any changes to the learned routes after applying the new policy. This work is
done in the background as part of an "Import Evaluation" job. When BGP is reconfigured
a second time, and the "Import Evaluation job" has not completed, it is necessary to
re-run the job from the beginning if there's another change to policy or something with
similar impact. This state is noted as "Import Evaluation Pending". However, in this
case, there was a bug that caused BGP to always enter the pending state upon
reconfiguration, regardless of whether relevant changes were made to import or other
similarly impactful configuration. The result is that once it is necessary to start
re-evaluation of the routes for a peer, even trivial configuration changes that happen
Copyright © 2016, Juniper Networks, Inc.
131
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
too quickly will cause the "Import Evaluation job" to need to run again as a result of
the "Pending" flag being set. To avoid the issue, please ensuring that "ImportEval" is
not present in a BGP peer's Flags output from the CLI (show bgp neighbor) prior to
doing even trivial commits. PR1120190
•
In multicast environment, when the RP is FHR (first hop router) and it has MSDP peers,
when the rpf interface on RP changed to MSDP facing interface, due to the multicast
traffic is still on the old rpf interface, a multicast discard route will be installed and
traffic loss will be seen. PR1130238
•
In multicast environment with Protocol Independent Multicast sparse mode (PIM SM)
used, if a upstream router of last-hop router receives the (S,G) SPT join while the
shortest-path tree (SPT) is not yet established (only because multicast source is not
reachable, a reachable route for SPT which is just not established yet will not cause
this issue), when the multicast route get deleted on the router (e.g. receives the (S,G)
prune from downstream PIM router), the router would incorrectly stop forwarding the
multicast traffic even if rendezvous-point tree (RPT) path exists. PR1130279
•
On dual RE platforms, due to software issue, OSPF (including both OSPFv2 and
OSPFv3) "DoNotAge" bit (e.g. source of LSA has flood-reduction feature enabled) is
not mirrored to backup routing protocol process (rpd). In this situation, after performing
nonstop active routing (NSR) switchover, the LSA on new master rpd remains without
"DoNotAge" bit set. Once the LSA reaches OSPF max age, the router will flood LSA
purge hence route flapping might be seen on all routers under the OSPF topology.
PR1131075
•
In rare condition, mt tunnel interface flap cause backup RE core. The exact root cause
is not known. While processing updates on the backup RE (received from master RE),
accessing free pointer cause the Core. PR1135701
•
On dual Routing Engine (RE) platform with Bidirectional Forwarding Detection (BFD)
protocol enabled, after graceful Routing Engine switchover (GRES), the periodic packet
management process (ppmd) might crash on backup RE due to a software defect.
PR1138582
132
•
With NSR configured, when the BFD sessions are replicated on backup RE, the master
won't send the source address, instead backup RE will query the kernel to get the
source address. In rare cases, the query might fail, resulting in the source address as
all zeros. Later, if a GRES switchover happens, new master will have this all zeros source
address. When BFD packet with this source address is send out, the other end will drop
the BFD session due to no matching session (source address). PR1145612
•
In the BGP labeled unicast environment, the secondary route is configured with both
add-path and advertise-external. If the best route and secondary route are changed
in a routing table at the same time, add-path might miss to readvertise the changed
route. The old route with the old label is still the last route advertised to one router
instead of updating the advertisement with the new route and new label. So the traffic
forwarding might be affected. PR1147126
•
This core is seen because of incorrect accounting of refcount associated with the
memory block which composes the nhid (IRB nh). When the refcount prematurely
reaches to 0 we released the memory block while it was still referenced from a route.
We may see this issue when mcsnoopd becomes a slow consumer of rtsock events
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
generated by rpd (nexthop events in the current case) and messages get delivered in
a out-of-order sequence causing the refcount to be incorrectly decremented. In the
testbed where the issue was reported, tracing was enabled for mcsnoopd (for logging
all events) causing it to become a slow consumer. However, it may become slow also
for other reasons such as processing very high rate of IGMP snooping reports/leaves
which could potentially trigger this to issue. PR1153932
•
Core seen when BMP station was passive, and the BMP Collector was terminated
non-gracefully, and BMP station was not properly cleaned up. PR1154017
Routing Policy and Firewall Filters
•
When a malformed prefix is used to test policy (command "test policy <policy name>
<prefix>"), and the malformed prefix has a dot symbol in the mask filed (e.g. x.x.x.x/.24),
the rpd process might crash. PR1144161
•
From Junos OS release 13.2R1, an attempt to commit a configuration with a dangling
conditional policy referring a non-existent/inactive routing-instance will be permitted.
If we have a conditional policy referring an active routing-instance, deleting/deactivating
this routing-instance and then committing will cause the rpd process crash. As a
workaround, we should always make sure that conditional policies are referring active
routing-instances. PR1144766
Services Applications
•
The Point-to-Point Tunneling Protocol (PPTP) ALG is used for tunneling Point-to-Point
Protocol (PPP) packets over an IP network. But if the router configures
session-limit-per-prefix, the PPTP-ALG does not work. PR1128484
User Interface and Configuration
•
When committing a config with very long as-path, in this case the as-path is almost
12000 characters long, the commitd process might crash. The commitd process restart
results in a minimal impact of system. As a workaround, please config as-path less
than 4096 characters long. PR1119529
•
When there are two or more sessions accessing the router, and one of the session (for
example, session 1) is executing commit check in configuration private mode, if another
session (for example, session 2) is keep executing commit and-quit in configuration
private mode, because the commit check is not keeping the lock on local RE for entire
session, there is a chance that session 2 will hit a Database opening error. The detailed
sequence events are as following: (1) Session 1: commit check is not keeping the lock
on local RE for entire session, once commit check on local is success, while it asked
for lock on other RE. (2) Session 2: mgd acquired db lock on local RE. (3) Session 1:
once commit check is completed on remote RE, it does cleanup and deleted the
juniper.data+ (created by Session 2). (4) Session 2: juniper.data+ is still in use at local
RE for by daemons and daemons start complaining about it and emitted the messages
as "Database open failed for file '/var/run/db/juniper.data+' ". PR1141576
VPNs
•
On dual RE platform with BGP L2VPN and NSR configured, there might be a chance
that the block label allocation and deletion for L2VPN is out of order on backup RE as
Copyright © 2016, Juniper Networks, Inc.
133
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
following: Master rpd follows the below sequeces (which is the correct order): Add
Prefix P1 of Label L1 Delete Prefix1 of Label L1 Add Prefix P2 of Label L1 However, on
backup rpd, it goes like this: Add Prefix P1 of Label L1 Add Prefix P2 of Label L1 <======
Delete Prefix1 of Label L1 In this situation, backup rpd cannot allocate the label L1 for
P2 since L1 is already in use for P1, so it crashes. This occurs in scaling environment (10k
L2VPN) where the router has multiple BGP peers and different L2VPN routing-instances
are deleted and added back. PR1104723
•
In L2circuit environment, if one PE has pseudowire-status-tlv configured but remote
hasn't, and at the same time, this PE doesn't support control-word but remote does,
then it will not send changed local status code to remote PE, in a rare condition, after
enable status-tlv support at remote end, the l2circuit might stuck in "RD" state on
remote PE. PR1125438
Resolved Issues: 14.2R5
•
Class of Service (CoS) on page 134
•
Forwarding and Sampling on page 135
•
General Routing on page 136
•
High Availability (HA) and Resiliency on page 140
•
Infrastructure on page 141
•
Interfaces and Chassis on page 142
•
Junos Fusion on page 145
•
Layer 2 Features on page 145
•
Layer 2 Ethernet Services on page 146
•
MPLS on page 146
•
Network Management and Monitoring on page 147
•
Platform and Infrastructure on page 147
•
Routing Policy and Firewall Filters on page 152
•
Routing Protocols on page 152
•
Services Applications on page 153
•
Software Installation and Upgrade on page 154
•
Subscriber Access Management on page 154
•
VPNs on page 154
Class of Service (CoS)
134
•
On MX104 platform, when we configure rate-limit for the logical tunnel (lt-) interface,
the commit will fail. As a workaround, we can use firewall filter with policer to achieve
the same function. PR1097078
•
On MX Series platform, when class-of-service (CoS) adjustment control profiles and
"overhead-accounting" are configured, if the ANCP adjust comes before the logical
interface (IFL) adding message and the IFL is in "UP" state when added (for example,
it may occur when carrying scaling subscribers, for instance, 8K subscribers), for some
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
of the subscribers, the local shaping rate from dynamic profile for the subscriber IFL
may not be overridden by shaping-rate of ANCP. PR1098006
Forwarding and Sampling
•
This defect is seen only when an existing child link from an AE is moved to a newly
created AE, simultaneously from both-ends. The new AE is listed as child link in the
existing AE in 'show interface ae<>.0 extensive' CLI. PR965872
•
The command "clear firewall all" will now clear the policer stats displayed by "show
policer __auto_policer_template_1__", ... "show policer __auto_policer_template_8__".
PR1072305
•
This issue is seen in Release 14.2 and later Junos OS. When Routing Engine based
sampling is enabled and BGP session is using 4 byte AS, improper AS number can be
found in sampling information. [router1]--------[DUT]--------[router2] AS 1,000 A AS
10,0000 | sampling 1.1.1.1 ---------------------->2.2.2.2 traffic --- traceoptions log --Aug 10 12:21:21 v5 flow entry Aug 10 12:21:21 Src addr: 1.1.1.1 Aug 10 12:21:21 Dst addr:
2.2.2.2 Aug 10 12:21:21 Nhop addr: 20.20.20.1 Aug 10 12:21:21 Input interface: 747 Aug 10
12:21:21 Output interface: 749 Aug 10 12:21:21 Pkts in flow: 594 Aug 10 12:21:21 Bytes in
flow: 49896 Aug 10 12:21:21 Start time of flow: 4648545 Aug 10 12:21:21 End time of
flow: 4707547 Aug 10 12:21:21 Src port: 0 Aug 10 12:21:21 Dst port: 2048 Aug 10 12:21:21
TCP flags: 0x0 Aug 10 12:21:21 IP proto num: 1 Aug 10 12:21:21 TOS: 0x0 Aug 10 12:21:21
Src AS: 1000 Aug 10 12:21:21 Dst AS: 34464 <<<<< Aug 10 12:21:21 Src netmask len: 32
Aug 10 12:21:21 Dst netmask len: 32 PR1111731
•
When "shared-bandwidth-policer" is configured with aggregate Ethernet (AE), if there
are filters configured on the logical interface family (IFF) of the AE interface, the FPC
may crash upon rebooting (it also be seen when new FPC coming up) due to the fact
that the running thread is stuck at the association of the filter which is in the resolved
state (it happens when the filter has not yet come down to the Packet Forwarding
Engine whereas its association has already reached). It is a timing issue in the above
circumstance, however, it could be consistently reproduced when moving links from
one AE to another and then rebooting the FPC by scripts. As a workaround, if it is
possible, the administrator could disable all the filter configuration and then bring up
the line card. PR1113915
•
On all Junos OS platforms, when both the filter and the policer are configured for an
interface, in rare cases, the policer template may not be received by Packet Forwarding
Engine (from the Routing Engine) when it is referenced by the filter term (normally the
policer template gets received before the filter term referencing it which is ensured by
mechanism in Routing Engine kernel). In this situation, the FPC would crash due to this
timing issue. This issue might be avoid by the recommended steps below: 1. Deactivate
the physical interface (IFD) and commit 2. Enable any filter and policer that attached
to the interface (e.g. IFL) and commit 3. Activate interface back PR1128518
Copyright © 2016, Juniper Networks, Inc.
135
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
General Routing
•
In a Layer 3 wholesale configuration, DHCPv6 advertise messages might be sent out
with source MAC all zeroes if the subscriber is terminated on the demux interface in a
non-default routing instance. For subscribers on default instance there is no such issue
observed. PR972603
•
MPC with Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC
(MIC-3D-4COC3-1COC12-CE) might crash. This problem is very difficult to replicate
and a preventive fix will be implemented to avoid the crash. PR1050007
•
In the PPP environment, when a subscriber is logged out, its IFL index is freed, but in
rare condition the session database (sdb) entry is not freed. When the IFL index is
assigned to a new IFL, it is still mapped to an old sdb entry, so the jpppd process might
crash because of mismatching. The issue is not really fixed, developer just adds some
debug information. PR1057610
•
When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP
routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP
routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the
rpd process might crash. PR1063796
•
When "satop-options" is configured on an E1 with Structure-Agnostic TDM over Packet
(SAToP) encapsulation, after Automatic Protection Switching (APS) switchover, some
SAToP E1s on the previously protect interface (now working) start showing drops.
PR1066100
136
•
Upon BFD flapping on aggregate interfaces, the Lookup chip (XL) might send illegal
packets to the center chip (XMCHIP) and compromise packet forwarding and an FPC
restart is needed to recover from this condition. If Fabric path side is affected, the fabric
healing process will initiate this process automatically to recover from such conditions.
MPC6E/MPC5E/NG-MPC are exposed to this problem. PR1067234
•
On MX Series platform with MS-MPC/MS-MIC, when Network Address Translation
(NAT), Stateful Firewall (SFW), Traffic Detection Function (TDF), or IPsec service is
configured and traffic flows, an ordered packet might miss the descriptor due to the
software defect. It results in prolonged flow-control, all data and control path are
blocked, the service PIC goes down and not come up. PR1079745
•
Scheduler: Protect: Parity error for tick table single messages might appear on
MPC3E/MPC4E/MPC5E/MPC6E/T4000-FPC5. PR1083959
•
TCP messages do not have their MSS adjusted by the Multiservices MIC and MPC if
they do not belong to an established session. PR1084653
•
mspmand core is observed while making ms-mic offline with IPSec and Jflow configured
on same ms-mic with dynamic IPSEC tunnels. PR1086819
•
On MX Series router with MPCs/MICs, if a rlsq interface is receiving continuous
fragmented traffic, doing rlsq switchovers couple of times might cause FPC to crash
and reboot. PR1088300
•
In a two members MX Series Virtual Chassis (MXVC) environment, when "set
virtual-chassis no-split-detection" is configured, if split master condition happens,
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
which is caused by split events (i.e. loss of all adjacencies by link failure, FPC restarts,
chassis power-down, RE reboots, etc), then once the VCP adjacency is formed again,
the current design could not determine best chassis to win the protocol mastership
election properly, instead, only the final election step (that is,choose the member
device with the lowest MAC address) is used to elect the master device (protocol
master of the VC, or VC-M). PR1090388
•
Wrong diagnostic optics info might be seen for GE-LX10 SFP and SFP+ for
SumitomoElectric. The issue only for a specific SFP type - "Xcvr vendor part number :
SCP6F44-J3-ANE”, it can be seen with "show chassis pic fpc-slot X pic-slot Y".
[email protected]> show chassis pic fpc-slot 0 pic-slot 0 .. PIC port information: Fiber Xcvr
vendor Wave- Xcvr Port Cable type type Xcvr vendor part number length Firmware 0 GIGE
1000LX10 SM OPNEXT INC TRF5736AALB227 1310 nm 0.0 1 GIGE 1000LX10 SM FINISAR
CORP. FTLF1318P2BTL-J1 1310 nm 0.0 2 GIGE 1000LX10 SM SumitomoElectric
SCP6F44-J3-ANE 1310 nm 0.0 <<<Error SFP type PR1091063
•
In a scaled Broadband Subscriber Management environment (in this case, 16K
subscribers), when Access Node Control Protocol (ANCP) cos adjustment is configured,
the minimum rate instead of the shaping-rate might be wrongly applied to some
subscribers and causes traffic loss. PR1094494
•
The issue is because of the software problem. Just after the system reboots, rpd process
is determining the RE mastership mode too early before chassisd is determining the
mastership , which would cause overload feature not to work properly. PR1096073
•
In occasionally , AFEB PCI reads from Cortona MIC with ATM OAM traffic might return
garbage values even though the actual content in the MIC has the correct value , this
corrupted values would lead to AFEB crash , and also PCI error logs such as : afeb0
PCI ERROR: 0:0:0:0 Timestamp 91614 msec. afeb0 PCI ERROR: 0:0:0:0 (0x0006)
Status : 0x00004010 afeb0 PCI ERROR: 0:0:0:0 (0x001e) Secondary bus status :
0x00004000 afeb0 PCI ERROR: 0:0:0:0 (0x005e) Link status : 0x00000011 afeb0
PCI ERROR: 0:0:0:0 (0x0130) Root error status : 0x00000054 afeb0 PCI ERROR:
0:0:0:0 (0x0134) Error source ID : 0x02580258 afeb0 PCI ERROR: 0:2:11:0 Timestamp
91614 msec. afeb0 PCI ERROR: 0:2:11:0 (0x0006) Status : 0x00004010 afeb0 PCI
ERROR: 0:2:11:0 (0x004a) Device status : 0x00000004 afeb0 PCI ERROR: 0:2:11:0
(0x0052) Link status : 0x00004001 afeb0 PCI ERROR: 0:2:11:0 (0x0104) Uncorrectable
error status : 0x00000020 afeb0 PCI ERROR: 0:2:11:0 (0x0118) Advanced error cap
& ctl : 0x000001e5 afeb0 PCI ERROR: 0:2:11:0 (0x011c) Header log 0 : 0x00000000
afeb0 PCI ERROR: 0:2:11:0 (0x0120) Header log 1 : 0x00000000 afeb0 PCI ERROR:
0:2:11:0 (0x0124) Header log 2 : 0x00000000 afeb0 PCI ERROR: 0:2:11:0 (0x0128)
Header log 3 : 0x00000000 PR1097424
•
After upgrading to Junos OS Release 14.1R1 and higher, loopback ISO family address
may be stuck in KRT queue. PR1097778
•
When route convergence occurred, the new gateway address is not updated correctly
in inline-jflow route-record table (route-record table is used by sampling), and the
sampling traffic forwarding might be affected, but normal routing would be not affected.
PR1097408
Copyright © 2016, Juniper Networks, Inc.
137
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
For Junos OS Release 13.3R1 and later, the DPC card might experience a performance
degradation when it's transferring bidirectional short packets (64B) in inline rate.
PR1098357
•
When the clock sync process (clksyncd) is stopped and resumed during link flaps, the
clksyncd process might get into an inconsistent state with various symptoms, the clock
source might be ineligible due to "Interface unit missing" or "Unsupported interface"
with no Ethernet Synchronization Message Channel (ESMC) transmit interfaces.
PR1098902
•
When BGP multipath is enabled in a Virtual Routing and Forwarding (VRF), if
"auto-export" and "rib-group" are configured to leak BGP routes from this VRF table
to another, for example, the default routing table, then traffic coming from the default
routing instance might not be properly load balanced due to the multipath-route leaked
into the default routing table is not the active route. This is a random issue. As a
workaround, only use "auto-export" to exchange the routes among the routing tables.
PR1099496
•
On XL-based cards such as MPC5/MPC6, PPE thread timeout errors (resulting in PPE
trap files) can be triggered when the FPC allocates illegal memory space for the
forwarding state of router operations. In certain cases, this can result in packet loss
depending on how many packets use this forwarding state. PR1100357
•
After Junos OS Release 13.3R1, IPCMON infra is added to debug IPCs between PFEMAN
and the Routing Engine. When convergence occurs, string processing of IPCMOM will
take added time. Then the slow convergence will be seen. It is a performance issue, it
is visible in scaled scenario (for example, more than 100K routes). As a workaround,
please execute command "set pfe ipclog filter clear" to disable IPC logging on all FPCs.
PR1100851
•
FFP is a generic process that shall be called during commit process, and FFP calls the
PDB initialization as part of its process. On the PDB-unsupported platforms (MX Series,
M10i, M120, M320 is PDB-supported), when committing configuration, some error
messages will be seen. PR1103035
•
Non-queuing MPC5E and MPC6E might crash continuously if rate-limit under
transmit-rate for scheduler is applied. As a workaround, do not configure rate-limit
and use firewall policer for forwarding-class instead. MPC5EQ is not exposed. PR1104495
•
When using "write coredump" to invoke a live coredump on an FPC in T Series, the
contents of R/SR ASIC memory (Jtree SRAM) will get dumped. In the situation that
there is a parity error present in the SRAM, then the coredump will abort and the FPC
will crash. As a workaround, configuring "set chassis pfe-debug flag
disable-asic-sram-dump" before "write coredump" will help to avoid the issue.
PR1105721
•
138
A vulnerability in OpenSSH may allow a remote network based attacker to effectively
bypass restrictions on number of authentication attempts, as defined by MaxAuthTries
settings on Junos. This may enable brute force password attacks to gain access to the
device. Background: The PAM (Pluggable Authentication Modules) library provides a
flexible framework for user authentication and session setup / teardown. It is used not
only in the base system, but also by a large number of third-party applications. Various
authentication methods (UNIX, LDAP, Kerberos etc.) are implemented in modules
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
which are loaded and executed according to predefined, named policies. These policies
are defined in /etc/pam.conf, /etc/pam.d/<policy name>, /usr/local/etc/pam.conf
or /usr/local/etc/pam.d/<policy name>. The PAM API is a de facto industry standard
which has been implemented by several parties. FreeBSD uses the OpenPAM
implementation. This issue is assigned CVE-2015-5600. PR1106752
•
When Bridge domain in PBB-EVPN Routing instance is modified to add/remove ISIDs
BD can get stuck in destroyed state. This happens when ISIDs in the Bridge domain
are changed from 1 to many or many to 1. This is only noticed during configuration
changes or initial deployment. PR1107625
•
Under IPv6 VRRP scenario, when a host sends router solicitation messages to VRRP
virtual IPv6 address, the VRRP master replies router advertisement messages with
physical MAC address instead of virtual MAC, the VRRP slave replies router
advertisement messages with physical MAC address as well. As a result, the host has
two default gateways installed and the host will send traffic directly to two devices
but not to the VRRP virtual IP. This issue affects VRRP function and traffic. PR1108366
•
Inverse multiplexing for ATM (IMA) interfaces on MIC-3D-4COC3-1COC12-CE may not
come up due to "Insufficient Links FE" alarm. This is due to data corruption on the
physical layer. PR1114095
•
The rpd process might crash when executing CLI command "show evpn database"
with the combination of "vlan-id" and "mac-address". PR1119301
•
In the scenario that the power get removed from the MS-MPC, but RE is still online (for
example, on MX960 platform with high capacity power supplies which split into two
separate power zones, when the power zone for the MS-MPC line card loses power by
switch off the PEM that supports the MS-MPC situated slot), if the power goes back
(for example, switch on the PEM), the MS-MPC might be seen as "Unresponsive"
(checked via CLI command "show chassis fpc") and not coming up back online due
to failure of reading memory. PR1112716
•
Under certain conditions, when the Junos OS Routing Engine tries to send an IP packet
over a IPIP tunnel, the lookup might end up in an infinite loop between two IPIP tunnels.
This is caused by a routing loop causing the tunnel destination for Tunnel#A to be
learned through Tunnel#B and the other way round. PR1112724
•
On all Junos OS platforms, when the Junos OS Routing Engine tries to send an IP traffic
over a GRE tunnel, the route lookup might end up in an infinite loop between two GRE
tunnels (the infinite loop is caused by a routing loop causing the tunnel destination for
Tunnel A to be learned through Tunnel B and the other way round), the kernel would
crash as a result. As a workaround, the issue could be avoided by preventing the tunnel
destination of a tunnel to be learned through a second tunnel (and the other way
round). PR1113754
•
On MX-VC with heartbeat connection, if it is in a scaled subscribers environment, when
power down both VCM REs, there might be a delay (minutes) for backup chassis to
be master and during which time, traffic blackhole might be seen. PR1115026
•
After VC Protocol Master Switch, new VCMm could allocate STP index of 1 (which is
global discarding state) to new IFDs resulting in STP status incorrectly marked to
discarding on the FPCs of the current VCBm. Please note for the fix to be effective, it
Copyright © 2016, Juniper Networks, Inc.
139
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
is required that MXVC setup is rebooted once after upgrade of all the Routing Engines
of the MXVC chassis with new fixed image following normal upgrade procedure and
hence unified ISSU based upgrades are not supported. PR1115677
•
For MPC6E with CFP2, there was a race condition between the Interrupt service routine
and the periodic, as a result interface up/down will not happen for laser off/on.
PR1115989
•
On MX240/MX480/MX960 platforms with MS-DPC card, in some race conditions,
after deactivating member interface of the aggregated multiservices (AMS) interface,
the service PIC daemon (spd) might crash due to memory corruption. As a workaround,
we should offline the member PICs before changing the AMS configuration and then
online the PICs. PR1117218
•
alg-logs and pcp-logs are not supported under [edit edit services service-set <ss-name>
syslog host local class] on ms interface as of now. Added warning message for the
same during configuration commit. PR1118900
•
In the multicast environment with pd interface (interface on the rendezvous point (RP)
that de-encapsulates packets), if execute GRES multiple times, and the GRES interval
is less than 30 minutes, the routes on master Kernel are added and deleted for a short
while. In rare condition, backup Kernel will not be able to see them. So after RE
switchover, the new master Kernel will delete next-hop ID for such routes, but Packet
Forwarding Engines will not see this deleted message. As a result, the Kernel/Packet
Forwarding Engines are out of sync for such particular next-hop ID, it might trigger a
reset of all the Packet Forwarding Engines. As a workaround, do the Routing Engine
switchover more than 30 minutes intervals. PR1119836
•
The commit latency will increase along with the increasing lines under [edit system
services static-subscribers group <group-name> interface]. Use ranges to create static
demux interfaces is a recommend option. e.g. [edit system services static-subscribers
group PROFILE-STATIC_INTERFACE] + interface demux0.10001001 upto
demux0.10003000; PR1121876
•
In multihoming EVPN scenario and the customer facing interface is an AE interface,
after moving an interface from the EVPN instance into a VPLS instance, traffic loss
might be seen on CE facing FPC. PR1126155
High Availability (HA) and Resiliency
•
On dual Routing Engine platform with NSR enabled, when committing scaling
configuration (for example, deactivating 500 IFLs and performing commit, then
activating 500 IFLs and commit, the process may need to be performed 3-6 times) to
the device, the master Routing Engine would be busy processing commit, due to which
the backup does not get data or keepalive from master. In this situation, the protocols
(for example, OSPF, or LDP) may get down on the backup RE due to keepalive timeout.
PR1078255
•
140
On MX Series Virtual Chassis (MX-VC) with scaled configuration, for example, 110000
DHCP and 11600 PPP subscribers, the unified in-service software upgrade (ISSU) might
fail due to the management daemon (MGD) timer expiring before Field-replaceable
units (FRUs) update finish. PR1121826
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Infrastructure
•
When "show version detail" CLI command has been executed, it will call an separate
gstatd process with parameter "-vvX". Because the gstatd could not recognize these
parameters, it will run once without any parameter then exit. In result of "show version
detail", following information could be seen: [email protected]> show version detail
Hostname: hostA Model: mx960 Junos: 13.3R6-S3 JUNOS Base OS boot [13.3R6-S3]
JUNOS Base OS Software Suite [13.3R6-S3] .. <snipped> file: illegal option -- v usage:
gstatd [-N] gstatd: illegal option -- v usage: gstatd [-N] <snipped> At the same time,
log lines like following might be recorded in syslog: file: gstatd is starting. file:
re-initializing gstatd mgd[14304]: UI_CHILD_START: Starting child '/usr/sbin/gstatd'
gstatd: gstatd is starting. gstatd: re-initialising gstatd gstatd: Monitoring ad2 gstatd:
switchover enabled gstatd: read threshold = 1000.00 gstatd: write threshold = 1000.00
gstatd: sampling interval = 1 gstatd: averaged over = 30 mx960 mgd[14304]:
UI_CHILD_STATUS: Cleanup child '/usr/sbin/gstatd', PID 14363, status 0x4000
mgd[14304]: UI_CHILD_EXITED: Child exited: PID 14363, status 64, command
'/usr/sbin/gstatd' PR1078702
•
On dual Routing Engine platform, if GRES is configured (triggered by "on-disk-failure"),
when a disk I/O failure occurs on the master Routing Engine due to hardware issue (for
example, SSD failure), the graceful Routing Engine switchover might not be triggered
immediately after initial IO failure has been detected. As a result, Routing Engine might
enter a state in which it responds to local pings and interfaces remain up, but no other
processes are responding. PR1102978
Copyright © 2016, Juniper Networks, Inc.
141
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Interfaces and Chassis
142
•
On MX Series platform, when an aggregated Ethernet bundle participating as L2
interface within bridge-domain goes down, the following syslog messages could be
observed. The messages would be associated with FPC0 even if there are no link(s)
from this FPC0 participating in the affected aggregate-ethernet bundle. mib2d[2782]:
SNMP_TRAP_LINK_DOWN: ifIndex 636, ifAdminStatus up(1), ifOperStatus down(2),
ifName xe-3/3/2 mib2d[2782]: SNMP_TRAP_LINK_DOWN: ifIndex 637, ifAdminStatus
up(1), ifOperStatus down(2), ifName xe-3/3/3 mib2d[2782]: SNMP_TRAP_LINK_DOWN:
ifIndex 740, ifAdminStatus up(1), ifOperStatus down(2), ifName ae102 fpc0 LUCHIP(0)
Congestion Detected, Active Zones f:f:f:f:f:f:f:f:f:f:f:f:f:f:f:f fpc0 LUCHIP(0) Congestion
Detected, Active Zones 2:0:0:0:0:8:a:0:0:0:0:0:8:4:0:a alarmd[1600]: Alarm set: FPC
color=RED, class=CHASSIS, reason=FPC 0 Major Errors craftd[1601]: Major alarm set,
FPC 0 Major Errors fpc0 LUCHIP(0) Congestion Detected, Active Zones
2:0:0:0:0:8:a:0:0:0:0:0:8:4:0:a alarmd[1600]: Alarm cleared: FPC color=RED,
class=CHASSIS, reason=FPC 0 Major Errors craftd[1601]: Major alarm cleared, FPC 0
Major Errors fpc0 LUCHIP(0): Secondary PPE 0 zone 1 timeout. fpc0 PPE Sync XTXN
Err Trap: Count 7095, PC 10, 0x0010: trap_nexthop_return fpc0 PPE Thread Timeout
Trap: Count 226, PC 34a, 0x034a: nh_ret_last fpc0 PPE PPE Stack Err Trap: Count 15,
PC 366, 0x0366: add_default_layer1_overhead fpc0 PPE PPE HW Fault Trap: Count
10, PC 3c9, 0x03c9: bm_label_save_label fpc0 LUCHIP(0) RMC 0 Uninitialized
EDMEM[0x3f38b5] Read (0x6db6db6d6db6db6d) fpc0 LUCHIP(0) RMC 1 Uninitialized
EDMEM[0x394cdf] Read (0x6db6db6d6db6db6d) fpc0 LUCHIP(0) RMC 2
Uninitialized EDMEM[0x3d9565] Read (0x6db6db6d6db6db6d) fpc0 LUCHIP(0)
RMC 3 Uninitialized EDMEM[0x3d81b6] Read (0x6db6db6d6db6db6d) These message
would be transient in nature. The discrepancy of nexthop handling that is addressed
in this PR can also manifest itself in form of other issues in the system. Basically when
the nexthops go out of sync we are bound to see either Packet Forwarding Engine
crashes/traps or Routing Engine crashes. The fix in this PR should take care of this
behavior and ensure we handle the nexthops correctly to maintain the synchronization
between master Routing Engine, backup Routing Engine and all Packet Forwarding
Engine peers. PR990023
•
dcd will crash if targeted-distribution applied to ge ifd via dynamic-profile PR1054145
•
It is observed that the syslog messages related to kernel and Packet Forwarding Engine
may get generated at an excessive rate, especially in subscriber management
environment. Most of these messages may appear repeatedly, for example, more than
1.5 million messages may get recorded in 2 hours, and there are only 140 unique
messages. Besides, these messages are worthless during normal operation and due
to the excessive rate of log generation, high Routing Engine CPU consumption (for
example, Routing Engine CPU utilization can be stuck at 100% for a long time (minutes
or hours), it depends on the activity of subscribers (frequency of logins and logouts)
and on the AI scripts used by the customer) by event process (eventd) might be
observed on the device. PR1056680
•
For Junos OS Release 13.3R1 and later, after multiple (e.g. 26) iterations of graceful
Routing Engine switchover (GRES), the TNP address of management interface might
be deleted incorrectly during switchover, which leads to all FPCs be offline. PR1060764
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Trap messages are not logged on logical interface (ifl) after deleting the "no-traps"
statement, in spite of setting explicit "traps". PR1087913
•
Deactivating/activating logical interfaces may cause BGP session flapping when BGP
is using VRRP VIP as source address. This is caused by a timing issue between dcd and
VRRP overlay file. When dcd reads the overlay file, it is not the updated one or yet to
be updated. This results in error and dcd stops parsing VRRP overlay file. PR1089576
•
In MX Series Virtual Chassis (MXVC) environment, when rebooting the system or the
line cards which contain all the Virtual Chassis port (VCP) links, because line cards
may fail to complete the rebooting process within 5 minutes, the timer (that is, the
amount of time allowed for the LCC to connect to the SCC) started by the master
router may expire which may cause the VCP links establishment failure. In addition,
this issue is not specific to the line cards type, based on the observation, the timer
(5min) may expire on a MX2020 with all 20 FPCs equipped as well. PR1095563
•
During failure notification state machine, CFM does not correctly transit from DEFECT
CLEARING state to RESET once the error indication has been cleared. As a consequence
all the forthcoming errors will be considered post errors and will be reported right away
without incurring the fngAlarmTime. This is a cosmetic problem. PR1096346
•
On PB-2OC12-ATM2-SMIR PIC, port 0 and port 1 are configured with clock source as
external, if Loss of signal (LOS) is inserted on port 0, the port 0 will down, the expect
behavior is clock being used from port 1. But in this case, port 0 down will results in port
1 flapping and reporting SONET phase lock loop (PLL) errors. PR1098540
•
In VRRP environment, with VRRP configured over double tagged interface and VRRP
delegate-processing enabled, the PDUs are generated with only one tag and the outer
tag is not added, because of which, the PDUs will get dropped at the receiving end.
The similar configuration that may cause the issue might be seen as below, .. protocols
{ vrrp { delegate-processing; <<<<< "delegate-processing" is enabled for VRRP } .. ..
interfaces { xe-0/0/3 { flexible-vlan-tagging; unit 0 { vlan-tags outer 2000 inner 200;
<<<<< VRRP is configured over double tagged interface family inet { address
10.10.10.147/29 { vrrp-group 17 { virtual-address 10.10.10.145; priority 100; accept-data;
} } } } } } .. PR1100383
•
After configuring related ae interface config, we might find some of ae interfaces
disappear in MX-VC. It seemed that ae interfaces are not allocated MAC address from
chassisd properly. * This issue only happens first configuration timing after
rebooting/restarting chassisd. So even if you configure related ae interface config
repeatedly, you cannot find this issue. When this issue happens these message will be
found in messages logs. ------------------------------------------------- [email protected]_re0>
show log messages| match CHASSISD_MAC_ADDRESS_AE_ERROR Jun 26 16:04:34.064
router_re0 scchassisd[2008]: CHASSISD_MAC_ADDRESS_AE_ERROR: chassisd MAC
address allocation error for ae4 Jun 26 16:04:34.105 router_re0 /kernel: Jun 26
16:04:34.064 router_re0 scchassisd[2008]: CHASSISD_MAC_ADDRESS_AE_ERROR:
chassisd MAC address allocation error for ae4
------------------------------------------------- Restore ae interfaces * This is not
workaround. deactivate/activate ae interfaces. (We need to do this to all disappeared
ae interfaces.) PR1100731
Copyright © 2016, Juniper Networks, Inc.
143
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Due to the fact that the error injection rate configured by user on Routing Engine via
CLI command "bert-error-rate" may not be programmed in the hardware register, the
PE-4CHOC3-CE-SFP, PB-4CHOC3-CE-SFP, MIC-3D-4COC3-1COC12-CE, and
MIC-4COC3-1COC12-CE-H may fail to inject bit errors during a Bit Error Ratio Test
(BERT). PR1102630
•
With "enhanced-ip" mode and AE interface configured, if SCU/DCU accounting is
enabled, the MS-DPC might drop all traffic as regular discard. PR1103669
•
The 'optics' option will now display data for VCP ports: show interfaces diagnostics
optics vcp-0/0/0 PR1106105
•
On MX240 or MX480 platform with at least two DC modules (PN: 740-027736)
equipped, when shutting down one of the PEMs and then turn it on again, even the
PEM is functioning, the "PEM Fan Fail" alarm might be observed on the device due to
software logic bug. There is no way to clear the ALARM_REASON_PS_FAN_FAIL for
I2C_ID_ENH_CALYPSO_DC_PEM once it has been raised. PR1106998
•
On MPC-3D-16XGE-SFPP line card, when an optics (for example, 10G-LR-SFP) is
disabled and then enabled administratively, if the SFP is not temperature tolerant
(non-NEBS compliant), the TX laser may not be turned on due to the fact that the
chassis process (chassisd) may keep sending the "disable-non-nebs-optics" command
to the optics if the current temperature of FPC reaches the threshold temperature.
PR1107242
144
•
On MX Series platform, continuous error messages might be seen on the MICs (for
10G/40G/100G MICs) from MIC3 onwards (listed as below) when physical interface
(IFD) settings are pushed (e.g. booting the MPC). Based on the current observation,
the issue may not have any operational impact and the MICs that may encounter this
issue are listed as below, - 10G MICs: MIC3-3D-10XGE-SFPP, MIC6-10G, MIC6-10G-OTN,
- 40G MICs: MIC3-3D-2X40GE-QSFPP, - 100G MICs: MIC3-3D-1X100GE-CFP,
MIC3-3D-1X100GE-CXP, MIC6-100G-CXP, MIC6-100G-CFP2 PR1108769
•
On all Junos OS platforms, if the "HDD /var" slice (for example, "/dev/ad1s1f" depending
on the type of Routing Engine) is not mounted (for example, label missing, file system
corrupted beyond repair, HDD/SDD is removed from the boot list, etc), the system may
build emergency "/var/", however, no alarm or trap is generated due to the incorrect
operation of the ata-controller. Although the boot messages may present the logs, it
may not be sufficient enough to identify the issue before encountering other problems
(for example, Junos OS upgrade failure and the Routing Engine may hang in a recovery
shell). In addition, as a method to check where Routing Engine is running from, a manual
check could be done as below, [email protected]> show system storage | match " /var$"
/dev/ad2s1f 34G 18G 13G 57% /var <<<Indicate that "/var" is mounted from the
HDD/SSD [email protected]>show system storage | match " /var$" <<<No output here, it
means that the RE is running from "emergency /var". PR1112580
•
Sometimes IQ2 PIC connection with kernel may drop after FEB redundancy switchover
under N:1 scenario, which will cause packets drop on this PIC. PR1120097
•
On Junos OS platform an aggregated-Ethernet bundle having more-than one member
link can show incorrect speed which wouldn't match to the total aggregate bandwidth
of all member links. The issue would be seen when LFM is enabled on the
aggregate-ethernet bundle. The issue would be triggered when one of the member
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
link flaps. Although after the flap, the current master Routing Engine would show
correct aggregate speed, the backup Routing Engine would report incorrect value. In
this state, when Routing Engine mastership is switched, the new master Routing Engine
(which was backup) will show incorrect value. One of the side-effect of this issue is
that RSVP also reflects incorrect Bandwidth availability for the affected
aggregated-Ethernet bundle, thus can cause under-utilization of the link with LSP
having bandwidth constraints. PR1121631
•
loopback sub-interfaces always have a Flag down in the output of CLI command "show
interfaces". PR1123618
•
The connectivity fault management (CFM) log message "Adjacency up" should only
be logged when the router first detects remote MEP or the peer interface goes down
and up causing adjacency failure for this remote MEP. But now it is wrongly logged
when any peer set/clear the Remote defect indication (RDI) bit in continuity check
messages (CCMs). PR1125164
Junos Fusion
•
When satellite-management is initially configured on an aggregation device, a timing
issue may prevent satellite-discovery-provisioning-process from providing access to
software upgrade or conversion to satellite devices. A retry mechanism has been added
to correct this. PR1131762
•
When Fusion is configured remote syslog may stop functioning. PR1134269
Layer 2 Features
•
In MX Series Virtual Chassis (MXVC) environment, when packets come from a interface
(for example, xe-16/0/1.542) situated on one member of VC (for example, VC member
1), if the ingress Packet Forwarding Engine (for example,FPC16 PFE0,who runs hash
to determine which interface it should send the packet to) decides that it should send
the packet via another interface (for example, xe-4/0/1.670) situated on different
member (for example, VC member 0), it will send the frame to member 0 via the vcpintf. In case of xe-4/0/1.670 belongs to an AE bundle which has multiple child links, a
hash need to be run on Packet Forwarding Engine carrying the VCP port (receiving side
on member 0) to determine which one is the egress Packet Forwarding Engine within
member 0 to send the packet out after vcp- intf gets the packet. This hash result should
get the same result as the ingress Packet Forwarding Engine. If it is not the case, then
the packet would get dropped on Packet Forwarding Engine on member 0. PR1097973
•
In a scenario that BGP based VPLS stitching with L2circuit, with "pseudowire-status-tlv"
configured under L2circuit's mesh-group, if L2circuit neighbor doesn't configure
"pseudowire-status-tlv", then status of "Negotiated PW status TLV" of VPLS
connection is "NO", this will cause BGP based VPLS connection can not up even the
L2circuit is up. PR1108208
Copyright © 2016, Juniper Networks, Inc.
145
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Layer 2 Ethernet Services
•
With scaled subscribers connected, restarting one of MPCs might cause subscribers
unable to log in for about 2 mins. PR1099237
•
V44 defines the next generation of Juniper Fabric using MX as the aggregation device
(AD) and EX4300/QFX5100Â’s as the Satellite Devices (SD). When V44 port extension
is in use, after switching from Master to Backup Routing Engine, the ppman daemon
on the SDs may crash and not be restarted. It results in the aggregated Ethernet (ae)
bundle over v44 extended ports does not come up. PR1101266
•
On MX Series platform with Dynamic Host Configuration Protocol (DHCP) maintain
subscriber feature enabled, after rebooting the FPC hosts the Demux underlying
interfaces, the next-hop for some DHCP subscribers might be marked as dead in the
forwarding table. When this issue occurs, we can execute CLI command "clear dhcp
server binding <address>" to restore. PR1118421
•
For PVSTP/VSTP protocols, when MX Series router inter-operate with Cisco device,
due to the incompatible BPDU format (there are additional 8 Bytes after the required
PVID TLV in the BPDU for Cisco device), the MX might drop these BPDUs. PR1120688
•
In scenario that DHCP relay is used along with Virtual Extensible Local Area Network
(VXLAN), if DHCP discover packet is received with the broadcast bit set via a VXLAN
interface on MX Series platform (which is acting as DHCP relay), the OFFER back from
the DHCP server will not be forwarded back to the client over the VXLAN interface.
Unicast offers (that is, DHCP offer packet with unicast bit set) over VXLAN and both
broadcast and unicast offers over native VLAN interfaces work fine. PR1126909
•
In some rare scenarios, the MVRP PDU might unable to be transmitted, which could
cause memory leak in layer 2 control plane daemon (l2cpd), and finally results in the
l2cpd process crash. PR1127146
MPLS
•
In Resource Reservation Protocol (RSVP) environment, if CoS-Based Forwarding (CBF)
for per LSP (that filter out traffic not related to that LSP) is configured, and either the
feature fast-reroute or link-protection is used on the device, when the primary link is
down (for example, turning off the laser of the link), due to some next hops of the
traffic may be deleted or reassigned to different class of traffic, and the RSVP local
repair may fail to process more than 200 LSPs at one time, the traffic may get dropped
by the filter on the device before the new next hop is installed. In this situation, the
feature (fast reroute or link protection) may take longer time (for example, 1.5 seconds)
to function and the traffic loss might be seen at the meantime. In addition, the issue
may not be seen if the CBF for per LSP is not configured on the device. PR1048109
•
Junk characters are being displayed in output of show connections extensive command.
PR1081678
•
146
When an LSP is link-protected and has no-local-reversion configured, if the primary
link (link1) is down and LSP on bypass (link2), then another link (link3) is brought up,
before the LSP switch to link3, if link1 is enabled and link3 is disabled, the LSP will stuck
in bypass LSP forever. This is a timing issue. PR1091774
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On dual Routing Engine platform with GRES, the kernel synchronization process
(ksyncd) may crash on the backup Routing Engine when adding of route pointing to
indirect nexthop on system. PR1102724
•
From Junos OS Release 13.2R1 and later, in MPLS L3VPN scenario, when
"l3vpn-composite-nexthop" knob is enabled on a PE router and an interface style
service set is attached to the ingress interface, the L3VPN packets with the MPLS labels
will be sent to the service card and dropped. As a workaround, we should disable
"l3vpn-composite-nexthop". PR1109948
•
If "optimize-timer" is configured under P2MP branch LSP, this branch LSP will not be
re-established if link flap on egress node. If "optimize-timer" is configured at
protocols/mpls level, issue could be avoided. PR1113634
•
For an MPLS L3VPN using LDP-signaled LSPs, in a rare racing condition (e.g. large-scale
environment or Routing Engine CPU utilization is high), the rpd process might crash
after an LDP neighbor down. PR1115004
Network Management and Monitoring
•
The SNMPv3 message header has a 4 byte msgID filed, which should be in
(0....2147483647), when the snmpd process has been running for a long time, the msgID
might cross the RFC defined range and causing Net-SNMP errors, "Received bad
msgID". PR1123832
•
From Junos OS Release 14.1R1, SNMP informs are not sent out to the network
management system (NMS) when significant events occur on a device running Junos
OS. As a workaround, we can configure an dummy trap-group. PR1127734
Platform and Infrastructure
•
On Junos OS based line cards with MPCs/MICs, when GRE keepalive packets are
received on a Packet Forwarding Engine that is different from the tunnel interface
hosted, the keepalive message will apply the firewall filter configured on default
instance loopback interface. PR934654
•
Bad udp checksum for incoming DHCPv6 packets as shown in monitor traffic interface
output. The UDP packet processing is normal, this is a monitor traffic issue as system
decodes checksum=0000. PR948058
•
In the dual Routing Engines scenario with NSR configuration, the statement "groups
re0 interfaces fxp0 unit 0" is configured. If disable interface fxp0, backup Routing
Engine is unable to proceed with commit processing due to SIGHUP not received, the
rpd process on backup Routing Engine might crash. PR974430
•
On Junos OS based line cards with MPCs/MICs, when learning the MAC address from
the pseudo IFL (for example, label-switched interface), if the MAC address is aged out
in source FPC where the MAC got learnt, due to the delay (around 2 to 3 milliseconds)
of MAC address deleting message processed in the source FPC and the egress FPC
(destination FPC of the traffic), the MAC address may be deleted first from the egress
Packet Forwarding Engine but get added again during these 2-3 milliseconds time
intervals (as these is continuous traffic coming on egress FPC destined to this MAC,
the MAC query is generated and send to Routing Engine and source FPC, since source
FPC has not yet process the MAC deleted message, it sends the response, so stale
Copyright © 2016, Juniper Networks, Inc.
147
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MAC will get added on the egress Packet Forwarding Engine), in this situation, no L2
flooding would occur for the "unknown" unicast (since the MAC address is present on
the egress Packet Forwarding Engine). PR1081881
148
•
If with both MPC/MSDPC and other type of DPCs equipped, for local switching at mesh
group level, split horizon on PW interfaces won't work and this would cause packets
to loop back to same PW interface. PR1084130
•
The MIB counter or "show pfe statistics traffic" shows junk PPS and invalid total traffic
output counter. PR1084515
•
If there are scaling unicast routes (e.g. 500k) in NG-MVPN VRF, and the provider-tunnel
is PIM, when PIM on PE has multiple upstream neighbors and any of them could be its
rpf neighbor, performing GRES/NSR Routing Engine switchover might cause multicast
traffic loss due to the different view of rpf neighbor between the master Routing Engine
and the slave Routing Engine. PR1087795
•
Issue is specific to 64-Bit RPD and config-groups wildcard config specific as in below
case: set groups TEST routing-instances <*> routing-options multicast
forwarding-cache family inet threshold suppress 200 set routing-instances vrf1
apply-groups TEST set routing-instances vrf1 routing-options multicast
forwarding-cache family inet threshold suppress 600 With this daemon(rpd) reads
suppressed value ?200? (i.e. coming from groups) instead of reading value ?600?from
foreground and customer sees unexpected behavior with respect to threshold-suppress.
Workaround: They can replace wildcard with actual routing-instance name as in below
example: set groups TEST routing-instances vrf1 routing-options multicast
forwarding-cache family inet threshold suppress 200 set routing-instances vrf1
apply-groups TEST set routing-instances vrf1 routing-options multicast
forwarding-cache family inet threshold suppress 600 PR1089994
•
On MX Series router, if ifl (logical interface) is configured with VID of 0 and parent ifd
(physical interface) with native-vlan-id of 0, when sending L2 traffic received on the
ifl to Routing Engine, the VID 0 will not imposed, causing the frames to get dropped at
Routing Engine. PR1090718
•
When a P2MP LSP is added or deleted at ingress LSR, traffic loss is seen to existing
sub-LSP(s) at transit LSR which replicates and forwards packet to egress PEs. This
issue only affects Junos OS based line cards with MPCs/MICs. PR1097806
•
The "shared-bandwidth-policer" statement is used to enable configuration of
interface-specific policers applied on an aggregated Ethernet bundle to match the
effective bandwidth and burst-size to user-configured values. But this feature is broken
from Junos release 14.1R1 when "enhanced-ip" is configured on MX Series platform
with pure MPCs/MICs. The bandwidth/burst-size of policers attached to ggregated
Ethernet interfaces are not dynamically updated upon member link flaps. PR1098486
•
On Junos OS based line cards with MPCs/MICs, when the type of the IPv6 traffic is
non-TCP or non-UDP (for example, next header field is GRE or No Next Header for
IPv6), if the traffic rate is high (for instance, higher than 3.5Mpps), the packet re-ordering
may occur. PR1098776
•
In an MPLS L3VPN network with a dual-homed CE router connected to different PE
routers, a protection path should be configured between the CE router and an alternate
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
PE router to protect the best path. When BFD is enabled on the BGP session between
the CE and the primary PE router, with local traffic flowing from another CE connected
with the primary PE to this CE, after bring down the interface on the best path, the local
repair will be triggered by BFD session down but it might fail due to a timing issue. This
will cause slow converge and unexpected traffic drop. PR1098961
•
When BFD or VRRP is running on a multi LU (lookup chip) Packet Forwarding Engine
(such as MPC3 or MPC4), some incoming BFD or VRRP packets might be incorrectly
evaluated by a firewall filter configured on a loopback interface of a different logical
system or routing instance. Therefore, packets might be unexpectedly discarded leading
to session/mastership flaps. PR1099608
•
On Junos OS based line cards with MPCs/MICs, before creating a new unilist nexthop,
there is a check to see if there is at least 512k DoubleWords (DW) free. So, even the
attempting NH requires only a small amount of memory (for example, < 100 DWs), if
there is no such enough free DWs (that is, 512k), the check will fail and the end result
is that the control plane will quit adding this NH prematurely - stopping at ~80% of
capacity. With the fix, it will check for 64k free DWs which is lower reference watermark
for available resource, thereby ensuring that can allocate resource. PR1099753
•
From Junos release 14.1 and later, IPv6 mobility packets with Heartbeat option that
the length of the mobility header (including the ethernet encapsulation and main IPv6
header) extends beyond 128 Bytes will be discarded as bad IPv6 option packet due to
a logic error in packet handling. PR1100442
•
Large scaled inline BFD session (in this case, 6000 inline BFD sessions) are loaded
with the minimum-interval value 50ms. If FPC restarts, some BFD sessions might flap.
PR1102116
•
A remote attacker can cause a denial of service to the MX Series router with MPC due
to maliciously crafted uBFD packets that are received directly, via VPN, MPLS, multicast,
broadcast, on vt-interfaces, or otherwise. This issue affects both IPv4 and IPv6 traffic
in both Ethernet, and non-Ethernet physical environments, such as ATM, or SONET,
where the crafted packet is received over physical interfaces. If processed from a DPC
through to the MPC then in-transit traffic will not be susceptible. In 6PE scenario, if the
system is not using LSI/vt then not susceptible. If processed via MPC line card will be
affected, the MPC line card will crash. If processed via endpoint receiving MPC line card
terminating tunneling protocols such as MPLS/IPSec VPNs, etc. will be affected, this
is considered in-transit traffic scenario. This crash can happen when the crafted packet
is directed directly to the lo0 interface IP/physical interface IP/broadcast IPv4 / IPv6
address of the Physical interface As a workaround, we can apply a control plane (lo0)
filter to drop uBFD packets. This issue is assigned CVE-2015-7748. More detailed
information in the below link:
http://kb.juniper.net/InfoCenter/index?page=content=JSA10701=SIRT_1& actp=LIST
PR1102581
•
On MPC3E/MPC4E line card, when the feature "flow-detection" is enabled (under
"ddos-protection" hierarchy), if suspicious control flow is received, two issues may
occur on the device: Issue 1: sometimes, the suspicious control flow may not get
detected on the line cards Issue 2: once the suspicious control flows are detected, they
may never time out even if the corresponding packets stop PR1102997
Copyright © 2016, Juniper Networks, Inc.
149
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The following fields have been added to v10 Sampling (IPFIX) template and data
packets: - SAMPLING RATE - SAMPLING INACTIVE TIMEOUT - SAMPLING ACTIVE
TIMEOUT - TOTAL PACKETS EXPORTED - TOTAL FLOWS EXPORTED PR1103251
•
On T4000 platform with FPC Type-5 equipped, after performing unified ISSU, due to
the fact that only 6 out of 16 temperature sensors may get initialized, the temperature
reading for the line card may be shown as "Absent". PR1104240
•
Any configuration or logical interface (IFL) change will introduce 160 bytes memory
leak on MPC heap memory when we have any type of inline sampling configured (ipfix
or version 9). Only trigger of issue is the configuration of inline sampling, even without
traffic being sampled. The leak is more evident in a subscriber management scenario
when we have many IFL addition/deletion. Rebooting MPC in a controlled maintenance
window is the only way to restore memory. PR1105644
•
When "shared-bandwidth-policer" is configured with aggregated Ethernet (AE) and
has more than one member link on the same Packet Forwarding Engine and the policer
is configured with "physical-interface-policer" statement, if reconfiguration occurs (for
example, adding/deleting new logical units, logical interface flap...), Packet Forwarding
Engine may problem wrong policer during this reconfiguration process, which could
ultimately lead to unexpected packet drop/loss within the referenced wrong shared
policer. PR1106654
•
When a common scheduler is shared by multiple scheduler maps which applies to
different VLANs of an Aggregated Ethernet (AE) interface, if the knob
"member-link-scheduler" is configured at "scale", for some VLANs, the scheduler
parameters are wrongly scaled among AE member links. As a workaround, we should
explicitly configure different schedulers under the scheduler maps. PR1107013
•
Due to a software defect found in 13.3R7.3 and 14.1R5.4 inclusively, Juniper Networks
strongly discourages the use of Junos OS Release 13.3R7.3 on routers with MQ-based
MPC. This includes MX Series with MPC1, MPC2, all mid-range MX Series router.
PR1108826
•
DHCP End options (option 255) is missing by DHCP-relay agent (where 20 bytes DHCP
options 82 inserted) for client DHCP discover message with 19bytes padding. PR1110939
•
An IPv4 filter configured to use the filter block with term that has both "from
precedence" and another non 5-tuple (i.e. not port, protocol, address) will cause an
XL/EA based board to reboot. Example: set firewall family inet filter FILTER
fast-filter-lookup set firewall family inet filter FILTER term TERM from precedence
PRECEDENCE set firewall family inet filter FILTER term TERM from tcp-established
PR1112047
150
•
With Junos release 14.2R4, on MX platform acting as the aggregation device (AD) in
Junos fusion solution, when unicast nexthops of extended ports are deleted and added,
the routing chip memory is not freed during the next-hop deletion. Two double words
will be leaked per nexthop deletion. PR1114369
•
When inline BFD sessions and inline jflow are configured on the same Packet Forwarding
Engine, with the increasing of active flows (about 65k), the BFD session might flap
constantly and randomly due to the outgoing BFD packets are dropped. PR1116886
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On MX Series router with FPC, when MPLS-labled fragmented IPv6 packets arriving
at PE router (usually seen in 6PE and 6VPE scenario), the Packet Forwarding Engine
might mistakenly detect such IPv6 header and then drop these packets as "L3
incompletes" in the output of "show interface extensive". PR1117064
•
When static inline NAT translation is used, if the translated source-prefix or
destination-prefix is modified for one NAT rule, it may impact the other NAT rules as
well. PR1117197
•
On MX Series routers with MPCs/MICs, the firewall filter may have some issues when
matching on Authentication Header (AH) protocol. This can affect VRRP (among
others) when authentication is used, and an Routing Engine firewall filter is matching
on protocol AH. As a workaround, we can change the filter to match on other criteria
(e.g. source or destination address). PR1118824
•
Tnetd is a daemon used for internal communication between different components
like Routing Engine and Packet Forwarding Engines(. It is used mainly to initialize the
right server for rsh, rcp, rlogin, tftp or bootp clients. It might crash occasionally due to
the tnetd process not handling signals properly. PR1119168
•
When the AC Single Phase Power Distribution Module (PDM) is installed on an MX2010
or MX2020 router running Junos release 14.1 or 14.2, the system does not recognize the
FRU and alarms are triggered as a result. PR1121068
•
After changing an outer vlan-tags, the ifl is getting programmed with incorrect stp state
(discarding), so the traffic is getting dropped. PR1121564
•
With "fast-synchronize" configured, adding a new configuration-group that has
configuration relevant to the rpd process and apply it and commit, then any
configuration commits might cause the rpd process on the backup Routing Engine
crash. We can reboot the backup Routing Engine to restore. PR1122057
•
On MX Series routers with MPCs/MICs, for GRE over IPv6 packet with layer 4 length
less than 8 bytes, it will be discard by reason "L4 len too short". PR1126752
•
After packets are subjected to NATing and deNATTing, TCP/UDP checksum normally
gets updated fine for non-fragmented packets. But in fragmented case, update of
TCP/UDP checksum is NPOT taken care properly which results in TCP/UDP checksum
failures at the receiving clients/servers. PR1128671
•
On device running Junos OS with DHCP Relay config but without accounting config,
and the accounting license does not exist, when the first DHCP control traffic is received,
the following subscriber-accounting license grace period alarms might be triggered:
alarmd[1650]: Alarm set: License color=YELLOW, class=CHASSIS, reason=License
grace period for feature subscriber-accounting(30) is about to expire craftd[1592]:
Minor alarm set, License grace period for feature subscriber-accounting(30) is about
to expire PR1129552
Copyright © 2016, Juniper Networks, Inc.
151
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Routing Policy and Firewall Filters
•
On the platform that M7i/M10i with enhanced CFEB, M320 with E3-FPC, M120, and
MX with DPC, when the flood filter is configured in VPLS instance on the Packet
Forwarding Engine, if the Packet Forwarding Engine receives a filter change (for example,
FPC reboot occur and comes up), the line card may fail to program the filter. PR1099257
Routing Protocols
152
•
Support for the Pragmatic General Multicast protocol (daemon pgmd) is being phased
out from Junos OS. In release 14.2 the CLI is now hidden (although the component is
still there and configurable). In release 15.1 the code and its corresponding CLI are
removed. PR936723
•
For FEC 129 VPLS (also known as LDP VPLS with BGP-based autodiscovery), if
abandoned VRF and VPLS instances are left after all of the other pieces of configuration
are removed, and the BGP protocol is deactivated in the master instance, the rpd
process might crash continuously when commit a new configuration. As a workaround,
we should remove all the unused VRF and VPLS instances. PR1006689
•
From Junos release 14.1R1 or above, the rpd process might crash while executing CLI
command "show isis backup spf results". PR1037114
•
EDITED MP 8/31 When a multicast group in protocol independent multicast (PIM)
dense mode has a large number of multicast sources, the RPD process can crash after
a routing engine switchover. PR1069805
•
There are two issues in the PR: (1) In multicast environment, Incoming interface list
(IIF) list has only RPF interface, designated forwarder (DF) winners are not added in
the list in backup Routing Engine. (2) "Number of downstream interfaces" in show pim
join extensive is not accounting Pseudo-VXLAN interface. PR1082362
•
On large scale BGP RIB, advertised-prefixes counter might show the wrong value due
to a timing issue. PR1084125
•
In BGP environment, when configuring RIB copy of routes from primary routing table
to secondary routing table (for example, by using the CLI command "import-rib [ inet.0
XX.inet.0]") and if the second route-table's instance is type "forwarding", due to the
BGP routes in secondary routing table may get deleted and not correctly re-created,
the routes may be gone on every commit (even commit of unrelated changes). As a
workaround, for re-creating the BGP routes in secondary route table, use CLI command
"commit full" to make configuration changes. PR1093317
•
Due to software bug JUNOS cannot purge so called doppelganger LSP, if such LSP is
received over newly formed adjacency shortly after receiving CSNP from the same
neighbor. PR1100756
•
When polling SNMP OID isisPacketCounterTable 1.3.6.1.2.1.138.1.5.3, the rpd process
might crash. PR1101080
•
When the ISIS configuration has been removed, the ISIS LSDB contents got flushed.
If at the same time of this deletions process, there is an SPF execution, which is trying
to access the data structures at same time when a fraction of secs after freeing its
content, routing protocol process (rpd) crash occurs. PR1103631
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
When the Multicast Source Discovery Protocol (MSDP) is used, if the RP itself is the
First-Hop Router (FHR) (i.e. source is local), the MSDP source active (SA) messages
are not getting advertised by the RP to MSDP peers after reverse-path forwarding
(RPF) change (e.g. the RPF interface is changed). PR1115494
•
When an interface is associated with a Bidirectional Forwarding Detection (BFD)
session, if changing the unit number of the interface (for example, change the unit
number for a running BFD session from ge-1/0/0.2071 to ge-1/0/0.285), the device
may fail to change the name due the missing check for logical interface (IFL) index
change. In addition, this is a software issue and may not have any service impact.
PR1118002
•
On dual Routing Engine platform with Nonstop active routing (NSR) and authentication
of the Bidirectional Forwarding Detection (BFD) session enabled, BFD process (bfdd)
memory leak may occur on the master Routing Engine and the process may crash
periodically once it hits the memory limit (RLIMIT_DATA). The problem does not depend
on the scale, but the leak will speed up with more BFD sessions (for instance 50
sessions). As a workaround, if possible, disabling BFD authentication will stop the leak.
PR1127367
•
When protocol MSDP is configured and then deleted, the NSR sync status for MSDP
might stuck in "NotStarted", and ISSU might fail on master Routing Engine with reason
"CHASSISD_ISSU_ERROR: Daemon ISSU Abort -1(NSR sync not complete: MSDP)".
PR1129003
Services Applications
•
When an MX Series router configured as an LNS sends an Access-Request message
to RADIUS for an LNS subscriber, the LNS now includes the Called-Station-ID-Attribute
when it receives AVP 21 in the ICRQ message from the LAC. PR790035
•
In the L2TP scenario with dual Routing Engines. After subscriber management
infrastructure daemon (smid) being restarted, because the delete notification to backup
Routing Engine might be lost, the subscriber database (SDB) information does not
synchronize between master Routing Engine and standby Routing Engine. After Routing
Engine switchover is executed, the Layer 2 Tunneling Protocol daemon (jl2tpd) might
crash, and new L2TP subscribers are unable to dial. PR968947
•
On an L2TP access concentrator (LAC) device with more than 8K L2TP sessions up,
if execute command "clear services l2tp session all" and then stop the command by
using ctrl-C, the Layer 2 Tunneling Protocol process (jl2tpd) might crash. PR1009679
•
When polling to jnxNatSrcNumPortInuse via SNMP MIB get, it might not be displayed
correctly. PR1100696
•
In Junos OS Release 13.3 and later releases, when configuring a /31 subnet address
under a nat pool, the adaptive services daemon (SPD) will continuously crash.
PR1103237
•
SIP one way audio calls when using X-Lite SIP Softphone, in case that SIP media is
switched to another media gateway though a SIP RE-Invite message PR1112307
Copyright © 2016, Juniper Networks, Inc.
153
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In CGNAT environment, when a service PIC is in heavy load continuously, there might
be a threads yielding loop in CPUs, which will cause the CPU utilization high, and might
cause one the CPUs to be reset. PR1115277
•
In CGNAT scenario, when we establish simultaneous TCP connects, we need to install
timers for each TCP connection/flow. Due to this bug, we ended up creating two timers
for the forward and reverse flow separately. Ideally there needs to be only one timer
for both the forward and reverse flow. Whenever the session used to get deleted due
to timer expiry, the PIC used to crash whenever the code tried to delete the same flow
again. PR1116800
Software Installation and Upgrade
•
Add "on <host>" argument to to "request system software validate" to allow validation
on a remote host/Routing Enginerunning Junos. PR1066150
•
In certain conditions, when /var is not mounted from a persistent filesystem, executing
a Junos OS upgrade will have unexpected results. This is caused by an inexact check
of whether we're running from an Emergency VAR. PR1112334
Subscriber Access Management
•
In scaled DHCP subscribers environment, the authd process might crash and generate
a core file after clearing DHCP binding or logout subscribers. PR1094674
•
Authd core dump in AaaService::cleanUpCliSessionInfo PR1127362
VPNs
•
In NG-MVPN spt-only mode with a PE router acts as the rendezvous point (RP), if there
are only local receivers, the unnecessary multicast traffic continuously goes to this RP
and dropped though it is not in the shortest-path tree (SPT) path from source to
receiver. PR1087948
•
In scenario involving pseudowire redundancy where CE facing interface in the backup
neighbor (can be non-standby, standby, hot-standby type), if the virtual circuit (VC)
is not present for the CE facing interface, the CE facing interface may go up after
committing an unrelated VC interface configuration (e.g. changing description of
another VC interface) even though the local pseudowire status is in down state.
PR1101886
154
•
In L2VPN or VPLS scenario with Junos release 14.2R4, after executing some negative
operations, e.g., deactivate/active BGP and IGP, or restart FPCs, the rpd process might
crash due to a NULL pointer access in code. PR1104472
•
In Internet multicast over an MPLS network by using next-generation Layer 3 VPN
multicast (NG-MVPN) environment, when rib-groups are configured to use inet.2 as
RPF rib for Global Table Multicast (GTM, internet multicast) instance, the ingress PE
may fail to add P-tunnel as downstream even after receiving BGP type-7 routes. In
addition, this issue only affects GTM. PR1104676
•
In Global Table Multicast (GTM) scenario (instance-type mpls-internet-multicast),
when the GTM instance and master instance are used, if the name of the GTM instance
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
is changed, the routing protocol process (rpd) may crash due to the usage of the
incorrect routing table handle. PR1113461
Resolved Issues: 14.2R4
•
Class of Service (CoS) on page 155
•
Forwarding and Sampling on page 156
•
General Routing on page 156
•
Infrastructure on page 161
•
Interfaces and Chassis on page 161
•
Layer 2 Features on page 163
•
MPLS on page 164
•
Platform and Infrastructure on page 164
•
Routing Policy and Firewall Filters on page 168
•
Routing Protocols on page 168
•
Services Applications on page 169
•
VPNs on page 170
Class of Service (CoS)
•
In SNMP environment, when performing multiple walks or parallel snmpget for same
interface at the same time (for example, SNMP bulk get/walk, or SNMP polling from
multiple devices) on CoS related MIBs (jnxCos table), if the interface state changes
or the request gets timeout when FPC is responding the request, memory leak of
Class-of-Service process (cosd) about 160 bytes (up to 1500 bytes) may occur, which
may cause cosd to crash eventually when limit is exceeded. PR1058915
•
Starting in Junos OS Release 12.3R1, on MX Series platform configured for IP
network-services (default) and with MS-DPC/Tunnel-Interface, virtual-tunnel (vt)
interfaces are created automatically to support ultimate-hop-popping upon enabling
"protocol rsvp". These interface are associated with default IP and MPLS classifiers
along with MPLS re-write rule. When "protocol rsvp" is disabled/enabled or
MS-DPC/FPC (with tunnel-service) restarts, the vt interfaces are deleted and re-added
to the system. However during the deletion, these interfaces are not getting released
from cosd process and thus leads to memory leak in cosd. PR1071349
•
On MX Series platform, when aggregated Ethernet (AE) interface is in link aggregation
group (LAG) Enhanced mode, after deactivating and then activating one child link of
the LAG , the feature that runs on AE interface rather than on the child link (for example,
IEEE-802.1ad rewrite rule) may fail to be executed. PR1080448
•
After restarting chassisd or doing a unified in-service software updgrade from Release
13.2R8.2 to 13.3R7.3 results in the following messages seen in syslog:
cosd_remove_ae_ifl_from_snmp_db ae40.0 error 2 Messages appear to be harmless
with no functionality impact. PR1093090
•
When performing the Routing Engine switchover without GRES enabled, due to the
fact that the Class-of-Service process (cosd) may fail to delete the traffic control
Copyright © 2016, Juniper Networks, Inc.
155
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
profile state attached to logical interface (IFL) index, the traffic-control-profile may
not get programmed after the ifl index is reused by another interface. PR1099618
Forwarding and Sampling
•
On MX Series router with MPCs/MICs, when deleting firewall filter and the routing
instance it is attached to, in some race conditions, the filter might not be deleted and
remains in resolved state indefinitely. PR937258
•
The issue is seen while moving an interface from one mesh group to another. Issue is
seen only on VMX intermittently. PR1077432
•
In some rare cases, SNMP might get Output bytes of Local statistics instead of the
Traffic statistics when retrieving Output bytes of Traffic statistics on a logical interface.
PR1083246
•
In rare cases, SSH or telnet traffic might hit incorrect filter related to SCU (Source Class
Usage) due to the defect in kernel filter match, this issue comes when the filter has
match condition on source class ID. PR1089382
•
In rare cases, MX Series routers might crash while committing inline sampling related
configuration for INET6 Family only. PR1091435
General Routing
156
•
On dual Routing Engine platforms, after performing unified graceful Routing Engine
switchover (GRES) with 8K subscribers, the ksyncd process may crash due to the
replication error on a next hop change operation. The issue is hit when there's memory
pressure condition on the Routing Engine and in that case, it may lead to null pointer
de-reference and ksyncd crash. Or in some cases, the kernel on the new master Routing
Engine might crash after Routing Engine switchover if Routing Engine is under memory
pressure due to missing null check when trying to add a next hop and the next hop is
not found at the time. PR942524
•
In point-to-point (P2P) SONET/SDH interface environment, there is a destination route
with this interface as next-hop. When this interface is disabled, the destination route
is still kept in the forwarding table and might cause ping fails with "Can't assign
requested address" error. PR984623
•
Optics lane#3 and lane#4 TX, RX power alarm data was ignored but the lane#1 and
lane#2 data was used for lane#3 and lane#4 respectively. Causing incorrect/false
alarm on lane#3 and lane#4 PR1001670
•
When there are no services configured, datapath-traced daemon is not running. In the
pic, the plugin continues to try for the connection and continuous connecion failure
logs are seen. PR1003714
•
During Wan Link flaps , ASIC streams in the Packet Forwarding Engines are
disabled/enabled on the fly when traffic is inflight. This is normal and will result in the
Cell drops, PKTR ICELL signature errors and SLOUT errors.However under certain rare
conditions , Lout IP -Pkt Len Mismatch error is observed which sometimes trigger
automatic restart of the FPC. On TXP,TXP-3D in FPC Type 4-ES can experience
automatic restart during wan interface flaps. PR1013522
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
SNMP MIB walk of object "jnxSpSvcSet" gives hardcoded value as "EXT-PKG" for
SvcType PR1017017
•
With Multiservices MPCs (MS-MPCs) or Multiservices MICs (MS-MICs) installed on
MX Series platform, when trying to view the Network Address Translation (NAT)
mappings for address pooling paired (APP) and/or Endpoint Independent Mapping
(EIM) from a particular private or a public IP address, all the mappings will be displayed.
PR1019739
•
On the Type 5 PIC, when the "hold-time down" of the interface is configured less than
2 seconds and the loss of signal (LOS) is set and cleared repeatedly in a short period
(for example, performing ring path switchover within 50ms), the "hold-time down"
may fail to keep the interface in "up" state within the configured time period. PR1032272
•
In MX Series Virtual Chassis (MXVC) environment, if the VC-ports are configured on
MPC2E-3D-NG, MPC2E-3D-NG-Q, MPC3E-3D-NG, and MPC3E-3D-NG-Q line cards
for which installed the corresponding Junos OS continuity package (Junos OS Continuity
package is a feature that allows new hardware to be deployed on already shipping
releases), the Virtual Chassis Port (VCP) ports are getting oscillated and the MPC is
crashing. MPC2E-3D-NG, MPC2E-3D-NG-Q, MPC3E-3D-NG, and MPC3E-3D-NG-Q
line cards are not supported on MX-VC in Junos OS Release 14.2R3. PR1034420
•
On MX Series router with MPC3E/MPC4E/MPC5E/MPC6E, if the Packet Forwarding
Engine has inline NAT configured or is processing inline GRE decapsulation with
packet-sizes between 100B-150B, in some very corner cases, traffic blackhole might
be seen due to incorrect cell packing handling On T4000 with FPC type 5, when these
cards are processing any packets sizes between 133B-148B, in certain sequences
incorrect cell packing handling results.PR1042742
•
Queue stats on LSQ interfaces are not properly cleaned up when queuing is enabled
on the IFD and the queues hosted at IFD level. This happens when a subsequent delete
and create of LSQ interface (not always though) - 14.1R4.10 PR1044340
•
As a precautionary measure, a periodic sanity check is added to FPC situated on
M7i/M10i with enhanced CFEB, M320 with E3-FPC, M120 and MX Series with DPC. It
checks FPC error conditions and performs the appropriate actions in case of an error.
PR1056161
•
On MX series routers, the interrupt-driven basis link down detection (an interrupt-driven
link-down notification is generated to trigger locally attached systems to declare the
interface down within a few milliseconds of failure) may fail after performing
unifiediIn-service software upgrade (ISSU). The interrupt might have been prevented
after performing unified ISSU due to disable the interrupt registers before ISSU but
never restored after. PR1059098
•
When a route points to an aggregated multiservices (AMS) logical interface, then after
manually bouncing this logical interface by disabling it and then enabling it again,
aggregate next hop referred by that route will have child unicast next hop pointing to
.discard.0 interface instead of member interface (mams) interfaces. As a result, traffic
ingress on MPC card and routed to that route will be discarded. PR1065944
•
When setting the syslog to debug level (any any), you may note reoccurring messages
of the form "ifa for this rt ia is not present, consider ifa as ready". These messages are
Copyright © 2016, Juniper Networks, Inc.
157
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
logged for IPv6 enabled interfaces when receiving forwarded packets and cause no
harm. Set a higher debug level to avoid seeing them. PR1067484
•
The static route prefers the directly connected subnet route for resolving the nexthop
rather than performing a longest prefix match with any other available routes. In case
of longest prefix route being desired in customer deployment, it will result in traffic loss
issue. Now a new configuration statement "longest-match" is introduced to enable
longest prefix matching behavior when desired: set routing-options static route
<destination-prefix> next-hop <address> resolve longest-match PR1068112
•
With basic NAT44, when the router receiving packets on GRE tunnel, NAT was dropping
all protocols other than PPTP on GRE tunnel. PR1069872
•
On MX Series routers with MPC based line cards in a setup involving Packet Forwarding
Engine fast reroute (FRR) applications, when BFD session flaps the next-hop program
in the Packet Forwarding Engine may get corrupted. It may lead to incorrect selection
of next-hop or traffic blackhole. PR1071028
•
Higher baseline CPU utilization and periodic CPU spikes might be seen on XM-based
MPC as compared to MPC-3D-16XGE-SFPP Cards due to below reasons: On XM-based
MPC, low priority threads which monitor various things in the background on a periodic
basis such as voltage, temperature, stats counters, hardware status and so on are
existed. When the system is idle these threads are allowed to take more of the load
and that is why higher baseline CPU/CPU spikes are seen. This does not prevent other
higher priority threads from running when they have to, as these are non-critical activities
being done in the background and hence is a non impacting issue. PR1071408
•
This is a timing issue, when kernel message for objects such as IFL or IFF come to dfwd
process after its dynamic profile delete request, the dfwd process might crash.
PR1074068
158
•
For Network Address Translation (NAT), Traffic Detection Function (TDF), or IPsec
service configured on MX Series platform with MS-MPC/MS-MIC, the received
fragmented IPv4/IPv6 packets will be re-assembled and sent out. Under scaled
environment, the mspmand process might crash while MS-MPC/MS-MIC is under
process of assembling the fragmented packets. PR1075454
•
Traffic throughput test between MPC1/1E/2/2E card and MPC2E/3E NG card, the
flowing from MPC1/1E/2/2E card to MPC2E/3E NG card is lesser then from MPC2E/3E
NG card to MPC1/1E/2/2E card. PR1076009
•
When a router with AMS infrastructure has MAC flow control enabled, the continuous
fragmented packets might crash the NPU and mspmand process (which manages the
Multi-Services PIC). PR1076033
•
On MX Series routers, the CLI command set interfaces interface-name speed
auto-10m-100m is not supported. PR1077020
•
The license-check process may consume more CPU utilization. This is due to a few
features trying to register with the license-check daemon which license-check would
not be able to handle properly and result in high CPU on Routing Engine. Optimization
is done through this fix to handle the situation gracefully so that high CPU will not
occur. PR1077976
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Starting in Junos OS Release 14.1R1, if the hidden knob "layer-4 validity-check" is
configured, the Layer4 hashing will be disabled for fragmented IP traffic. Due to a
defect, the Multicast MAC rewrite is skipped in this case, the fragmented multicast
packets will be sent with incorrect destination MAC. PR1079219
•
In subscriber management environment, the PPP daemon (jpppd) might crash
repeatedly due to a memory double-free issue. PR1079511
•
On MX Series platform with MS-MPC/MS-MIC, in some mspmand process crash
scenarios, after the mspmand coredump is finished or almost finished, PIC kernel also
crashes and dumps vmcore. The mspmand cores in these scenario are readable but
vmcores are not. PR1081265
•
This may be a false log message - the risk of false log is minor, however the underlying
error, e.g. continuous fi recorder timeout, may impact traffic and can be major. When
the specific log message is observed in the message file, please advise customer to
investigate if there are continuous fabric errors, such as late cell, cell timeout etc, on
the reporting linecard and recover those errors first. PR1081771
•
'show interfaces queue <ifl>' stats are not correct with RLSQ warm-standby mode.
Issue seen on MPCs and MICs as well in 14.1R4.10 PR1082417
•
The rpd process might crash on both master and back up Routing Engine when a routing
instance is deleted from configuration, if the routing instance is cleaned up before the
interface delete is received from device control daemon (dcd). This is a rare timing
issue. PR1083655
•
OTN based SNMP Traps such as jnxFruNotifOperStatus and
jnxIfOtnNotificationOperStatus are raised by offline/online MIC although no OTN
interface is provisioned PR1084602
•
Invalid Ethernet Synchronization (ESMC) frames may be transmitted by MX Series
router when activating LAG and tag-protocol-id under interfaces. PR1084606
•
On a device with lt and ams interfaces configured, walking ifOutOctets or other similiar
OIDs may cause a "if_pfe_ams_ifdstat" message to print. This is a cosmetic debug-level
entry, which was incorrectly set to critical-level. PR1085926
•
In some rare conditions, depending on the order in which configuration steps were
performed or the order in which hardware modules were inserted or activated, if PTP
master and PTP slave are configured on different MPCs on MX Series router acting as
BC, it might happen that clock is not properly propagated between MPCs. This PR fixes
this issue. PR1085994
•
MACsec using static secure association key (SAK) security mode does not work properly
on MX80 routers and FPC slots other than slot 0 of MX104 routers. PR1086117
•
mspmand.core is observed while making ms-mic offline with IPsec and Jflow configured
on same ms-mic with dynamic IPsec tunnels. PR1086819
•
If the ALG is receiving UDP fragmented control traffic (e.g. SIP control packets)
continuously, the mspmand process (which manages the service PIC) might crash due
to buffer error. PR1087012
Copyright © 2016, Juniper Networks, Inc.
159
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In the specific configuration of a LT interface in a VPLS instance and the peer-unit of
this LT interface configured with family inet6 using vrrp, the kernel may crash when
the FPC is online. PR1087379
•
Incorrect ESH checksum computation with non zero Ethernet in MX Series router.
PR1091396
•
In a fib-localization scenario, IPv4 addresses configured on service PICs (SP) will not
appear on FIB-remote FPCs although all local (/32) addresses should, regardless of
FIB localization role, install on all Packet Forwarding Engines. There is no workaround
for this and it implies that traffic destined to this address will need to transit through
an FIB-local FPC. PR1092627
•
Mspmand core due to prolonged flow-control with TCP ALGs under the following
possible scenario, mostly when the following conditions happen together 1. When the
system is overloaded with TCP ALG Traffic. 2. There are lot of retransmissions and
reordered packets. PR1092655
•
When the control path is busy/stuck for service PIC, the AMS member interface hoisted
by it might be down, but when the busy/stuck condition is cleared, the member interface
might not recover, and AMS bundle still shows the PIC as inactive. PR1093460
•
On TCP ALG, if there are a lot of retransmission and reordered TCP packets, and the
system is overloaded due to the TCP traffic, the mspmand (which manages the service
PIC) process might crash. PR1093788
•
There are entries for PEM in jnxFruEntry in VMX. It is not necessary and is cosmetic.
PR1094888
160
•
Extensive Header integrity checks will be done for packets that match a service set
that has NAT/SFW configured. 1. Enable Header Integrity checks by default when SFW
or NAT is configured in same service-set. This is inline with ukernel behavior 2. Retain
the knob for use by other plugins such as IPsec which may want to enforce header
integrity if needed 3. ensure that the command "show services service-sets statistics
integrity-drops" works if SFW/NAT is configured PR1095290
•
If a service-PIC is configured to simultaneously function as both an MS interface and
as a member of an AMS interface, then some settings under services-options may not
apply correctly. These settings are A) syslog_rate_limit, B) fragment-limit, C)
reassembly-timeout and D) jflow_log_rate_limit. PR1096368
•
Non-queuing MPCs might crash continuously if rate-limit is applied. As a workaround,
do not configure rate-limit on them. PR1104495
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Infrastructure
•
When the Ethernet Link Fault Management (LFM) action profile is configured, if there
are some errors (refer to the configuration, for example, frame errors or symbol errors)
happening in the past (even a long past), due to the improper handling of error stats
fetching from kernel, the LFM process (lfmd) may generate false event PDUs and send
the false alarm to the peer device. PR1077778
Interfaces and Chassis
•
Power-off by pushing Offline button on master Routing Engine causes lots of packets
lost although GRES/NSR is configured. FPC gets rebooted after Routing Engine switch
over which also causes traffic loss. PR1034164
•
In Virtual Router Redundancy Protocol (VRRP) environment, after restarting the FPC,
due to the Router Advertisement (RA) deletion is being incorrectly sent to routing
protocol process (rpd) by VRRP process, the ICMPv6 may not be activated on the
corresponding interfaces on the router that is acting as the master. In this case, no RA
message could be sent out. PR1051227
•
The "show chassis network-services" command might not show the correct configured
value when executed on the backup Routing Engine. This command should only be
executed on the master Routing Engine. PR1054915
•
On DPC only chassis, after software upgrade or not graceful Routing Engine switchover,
Ethernet OAM related LAG bundles might not come up due to the Link Fault
Management (LFM) packets arrive on AE interface instead of physical link interface.
PR1054922
•
There is a mismatch in mac statistics, where few frames go unaccounted. This is a
day-1 issue with the software fetching of mac statistics. The snap and clear bits were
set together on pm3393 chip driver software, so even before the copy of stats to shadow
registers happened, clear was happening which used to be unaccounted. PR1056232
•
When the Maximum Receive Unit (mru) value is not set under group-profile ppp-options
hierarchy, a default value (1492) will be used. If mru value is set, the new value will
take effect. But if the configured mru value is deleted from the group profile, the mru
value remains the configured one and fails to fall back to the default one. PR1059720
•
For transit traffic on INLINE LSQ redundancy (rlsq) interface, the input firewall-filter
counters are logging zero packet count regardless of traffic flow. Output filter counters
are logging correctly. For host-bound traffic, the firewall output counter will get double
accounted on Classical rlsq and triple accounted on INLINE rlsq. This issue is targeted
to be fixed in Junos OS Release 14.1R5. PR1060659
•
In scaling PPP subscriber environment, when the device is under a high load condition
(for example, high CPU utilization with 90% and above), the long delay in session
timeout may occur. In this situation, the device may fail to terminate the subscriber
session (PPP or PPPoE) immediately after three Link Control Protocol (LCP) keepalive
packets are missed. As a result, subscriber fails in reconnect due to old PPP session
and corresponding Access-Internal route are still active for some time. In addition to
this, it is observed that the server is still sending KA packets after the session timed
out. PR1060704
Copyright © 2016, Juniper Networks, Inc.
161
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On MX Series routers, INET MTU (PPP payload MTU, that is IP header plus data
excluding any L2 overhead) is being set to lowest MRU of either MX (local device) or
peer. This behavior is not inline with ERX behavior, which is set to min(local MTU, peer
MRU). This might cause the packet drops in the customer network in the downstream
path. PR1061155
•
When adding new VCP port MX-VC, some of traffic drops are seen. PR1067111
•
On MX Series Virtual Chassis (MX-VC) platform, due to a timing issue, the physical
interface (ifd) on the same Modular Interface Card (MIC) with Virtual Chassis port
(VCP) might not be created or take a very long time to be created after reboot the
hosted Modular Port Concentrator (MPC). PR1080032
•
MAX-ACCESS value has been changed in jnx-otn.mib for the following oids:
jnxOtnIntervalOdu15minIntervalNumber jnxOtnIntervalOtu15minIntervalNumber
jnxOtnIntervalOtuFec15minIntervalNumber The value has been changed from read-only
to not-accessible to be inline with newer MIBs. PR1080802
•
In MX Series Virtual Chassis (MXVC) scenario, during unified ISSU operation, the new
master Routing Engine does not have the MXVC SCC's system MAC address. It just
has its local system MAC address. The address is not replicated between local Routing
Engines, and the new master Routing Engine has not yet connected to the MXVC SCC
to receive it. Hence, the possibility exists to overwrite the FPC with an address that
does not match the previous address. PR1084561
•
The VRRP preempt hold time is not being honored during NTP time sync and system
time is changed. PR1086230
•
On MX Series Virtual Chassis (MX-VC) platform with "subscriber-management"
enabled, after power up/reboot, the VC backup router (VC-B) experiences a rapid
sequence of role transitions from no-role to VC master router (VC-M) to VC-B, the
expected local GRES and a reboot of the former master Routing Engine might not
happen on the VC-B, some of the FPCs on it might be stuck in "present" state and
eventually rebooted. PR1086316
•
In the dual Routing Engines scenario with GRES and ae0 interfaces configuration, if
GRES is disabled on system, the backup Routing Engine should remove the ae0 bundle,
however it doesn't go clean and ae0 remains in backup Routing Engine. After switching
Routing Engine mastership to make other Routing Engine as master, the new master
Routing Engine (which was backup earlier) continues to use invalid MAC address
"00:00:00:00:00:00". PR1089946
•
When an interface on SFPP module in MIC is set disabled, after pulling out the SFPP
and then insert it, the remote direct connected interface might get up unexpectedly.
PR1090285
162
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Layer 2 Features
•
BGP peer configured between two routers over lt (logical tunnel) interface, if deactiving
and activing scaled configuration a few times, in rare condition, the lt interface might
reject all the ARP reply packets, and hence the ARP resolution does not happen over
this interface, so the unicast routes are not in the correct states, ping to such an lt
interface will fail. PR1059662
•
With Dynamic Host Configuration Protocol (DHCP) maintain subscriber feature enabled,
when the subscriber's incoming interface index is changed, for example, the interfaces
go away and come back after changing the MTU configuration of interface, the existing
subscribers may get dropped and new subscribers fail in connection. PR1059999
•
LACP partner system ID is shown wrong when the AE member link is connected to a
different device, this might misguide while troubleshooting the LAG issues. PR1075436
•
On MX series routers, when configuring the dynamic access routes for DHCP subscribers
based on the Framed-Route RADIUS attribute, the access route may be created on
the device, however, the framed routes may not be installed for subscriber interface
(under the "Family Inet Source Prefixes"). PR1083871
•
MTU change is not advised on the Ethernet ring protection (ERP) ring interfaces unless
ring is in idle condition. Changing ring interface MTU while ring is not in idle state may
result in change in the forwarding state of the interface and which can lead to loop in
the ring. PR1083889
•
When family bridge was configured and committed, l2ald repeated restarting with
core. After l2ald repeated restarting several times, it stopped working due to thrashing
condition. Core of l2ald will be seen with the configuration below. set interfaces fxp0
unit 0 family bridge interface-mode access set interfaces fxp0 unit 0 family bridge
vlan-id 100 When the configuration is committed, message like following is logged
and core is generated. l2ald[1624]:
../../../../../src/junos/usr.sbin/l2ald/l2ald_vpls_flood.c:3117: insist '!err' failed l2ald[1734]:
../../../../../src/junos/usr.sbin/l2ald/l2ald_vpls_flood.c:3117: insist '!err' failed l2ald[1769]:
../../../../../src/junos/usr.sbin/l2ald/l2ald_vpls_flood.c:3117: insist '!err' failed l2ald[1993]:
../../../../../src/junos/usr.sbin/l2ald/l2ald_vpls_flood.c:3117: insist '!err' failed l2ald[2195]:
../../../../../src/junos/usr.sbin/l2ald/l2ald_vpls_flood.c:3117: insist '!err' failed ... init:
l2-learning is thrashing, not restarted PR1089358
•
During interface flaps a high amount of TCN (Topology Change Notification) might
get propagated causing other switches to get behind due to high amount of TCN
flooding. This problem is visible after the changed done from 11.4R8 onwards which
propagates TCN BPDU immediate and not in the pace of the 2 second BPDU Hello
interval to speed up topology change propagation. The root cause is the TCNWHILE
timer of 4 seconds is always reset upon receiving TCN notifications causing the high
churn TCN propagation. PR1089580
Copyright © 2016, Juniper Networks, Inc.
163
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MPLS
•
LDP is not distributing a label for BGP FEC/prefix to downstream on demand (DoD)
sessions when Forwarding Equivalence Class (FEC)/prefix learned this from IBGP peer
to whom ldp-tunneling is configured. PR1049329
•
With BGP prefix-independent convergence (PIC) edge feature enabled, more than one
BGP next-hop association will be installed in the Packet Forwarding Engine for MPLS
VPN and Internet transit traffic. Deactiving/activating the IGP protocol (IS-IS or OSPF)
might cause the backup session to stay down on Packet Forwarding Engine. PR1058190
•
With BGP labeled-unicast egress protection enabled in a Layer 3 VPN, the protected
node advertises primary BGP labeled unicast routes that needs protection. When there
is next-hop change for a labeled route, for example, deactivating/activating
egress-protection knob or route churn, the memory might be exhausted and it leads
to the rpd process crash. PR1061840
•
The point-to-multipoint (P2MP) label-switched path (LSP) is unable to re-established
after certain links are down. This issue might be encountered when the links are those
that contain the primary and backup LSPs for the P2MP LSP. The P2MP LSP can be
restored after the links are up. PR1064710
•
When CSPF computes the path for node-protected bypass, it considers only the SRLG
group configured on next-hop interface along the primary path. However it doesn't
consider the SRLG group on next-to-next-hop interface to adequately provide diverse
path between primary and node-protected bypass. PR1068197
•
In scaled l2circuits environment, the rpd process might crash due to a corruption in the
LDP binding database. PR1074145
•
In MPLS environment, if one of
minimum-signaling-bandwidth/merging-bandwidth/splitting-bandwidth/maximum-s
ignaling-bandwidth is configured, or derived as value 0, the routing protocol process
(rpd) may crash when lsp-splitting or lsp-merging (for example, when the traffic comes
up/down) occurs. As a workaround, due to the logic of the knobs, none of the following
knobs could be configured or derived as zero, -merging-bandwidth
-minimum-signaling-bandwidth -splitting-bandwidth -maximum-signaling-bandwidth
PR1074472
•
In race conditions, the rpd process on backup Routing Engine might crash when BGP
routes are exported into LDP by egress-policy and configuration changes during the
rpd process synchronizing the state to backup rpd process. PR1077804
Platform and Infrastructure
164
•
When Network Configuration Protocol (NETCONF) service is used on the device, after
the NETCONF session is established, because all the output that contain <error> tag
might be incorrectly converted into <rpc error>, the management daemon (mgd) may
crash on the device. As the example below, the output that contains <error> tag may
lead to the crash. [email protected]> show subscribers address 1000 | display xml .. <error>
<<<<<< The output contain <error> tag and may trigger the crash PR975284
•
On MX Series Virtual Chassis (MX-VC) platform, mirroring of OAM packets may not
work as expected if the OAM packet traversing through multiple Packet Forwarding
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Engines (for example, the mirrored port and VCP port are on separate Packet Forwarding
Engines). PR1012542
•
In EVPN scenario, MPC may crash with core-dump when any interface is deleted and
add that interface to an aggregated Ethernet bundle or changing the ESI mode from
all-active to single-active. PR1018957
•
LSI logical interface input packet and byte stats are also added to core logical interface
stats, but when the LSI logical interface goes down and the core logical interface stats
are polled, there is a dip in stats. The fix is to restore LSI logical interface stats to core
logical interface before deleting the LSI logical interface. PR1020175
•
Due to a defect in the Junos Software, when a telnet user experiences some undefined
network disconnect, .perm and .env files under /var/run are left behind. This scenario
happens only under certain unknown ungraceful network disconnects. When
considerable number of .perm/.env files get accumulated under /var/run, issue is seen
with telnet users, that they are not able to perform permitted operations on the router,
post-login. PR1047609
•
Under very rare situations, Packet Forwarding Engines on the following linecards, as
well as the compact MX80/40/10/5 series, may stop forwarding transit traffic: 16x10GE MPC - MPC1, MPC2 This occurs due to a software defect that slowly leaks
the resources necessary for packet forwarding. Interfaces handled by the Packet
Forwarding Engine under duress may exhibit incrementing 'Resource errors' in
consecutive output of 'show interfaces extensive' output. A Packet Forwarding Engine
reboot via the associated linecard or chassis reload is required to correct the condition.
PR1058197
•
With the configuration "extend-size", if user loads and commits scaled configuration
(in this case, 250K Unique Prefix list policy options), then deletes the knob "extend-size",
the dfwd process might crash. PR1058579
•
If a Radius server is configured as accounting server, when it is non-reachable, the
auditd process might stressed with huge number of audit logs to be sent to the
accounting server, which might cause auditd to crash. PR1062016
•
Starting from Junos OS Release 14.2R1, the CLI command "set date ntp a.b.c.d" may
not be working. PR1067107
•
StartTime and EndTime of the flow in inline-jflow (version 9) has future time-stamp
PR1067307
•
Having "shared-bandwidth-policer" on an aggregated ethernet interface; if a member
interface flapped, the NPC which the interface belongs may restart. The similar issue
may also happens when changing firewall policer configuration. PR1069763
•
If with about 1M routes on MX series router, there might be more than 1 second (about
1.3s) packets dark window during ISSU. PR1070217
•
If port-mirroring and VRRP over ae-irb is configured in a bridge-domain, enabling the
Distributed Periodic Packet Management Process (ppmd) for VRRP in this BD might
cause the VRRP to flap. PR1071341
Copyright © 2016, Juniper Networks, Inc.
165
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
when inline-sampling is enabled, in race conditions, if packet gets corrupted and the
corrupted packet length shows 0, which may cause "PPE_x Errors thread timeout error"
and eventually cause MPC card to crash. PR1072136
•
VRRP advertisements might be dropped after enable delegate-processing on the
logical tunnel (lt) interface. It would result in VRRP master state observed on both
routers. PR1073090
•
When Integrated routing and bridging (IRB) interface is configured with Virtual Router
Redundancy Protocol (VRRP) in Layer 2 VPLS/bridge-domain, in corner cases after
interface flapping, MAC filter ff:ff:ff:ff:ff:ff is cleared from the Packet Forwarding Engine
hardware MAC table, so the IRB interface may drop all packets with destinations MAC
address FFFF:FFFF:FFFF (e.g. ARP packet). PR1073536
•
Problem: It tries to check allotted power for all the FPCs, here in the
CHASSISD_I2CS_READBACK_ERROR logs it shows for the FPCs which are not present
in chassis. It just calls i2cs_readback() to read i2c device and fails there as these FPCs?
slots are blank and prints those readback errors. Also the errors are harmless:
"CHASSISD_I2CS_READBACK_ERROR: Readback error from I2C slave for FPC" Fix:
Code to check 'if power has been allotted to this FPC', needs to be executed only if the
FPC is present. PR1075643
•
In Hierarchical class of service (H-CoS) environment, when the subscriber logout from
the reserved logical interface (ifl) ".32767" unit (for example, xe-x/x/x.32767), the CoS
installation of the interface may get wrongly deleted on Packet Forwarding Engine.
PR1077098
•
MPC is showing the below log messages and will generate core.
jnh_private_mem_pool_free(898): No private mem_pool for 0x00300000/00100000
PR1081855
166
•
When a MX chassis network-services is "enhanced-ip" and an AE is part of a Layer 2
bridge (bridge-domain or VPLS), there is a possibility that an incorrect forwarding path
may be installed causing traffic loss. This could happen when first applying the
configuration, restarting the system or restarting the line card. PR1081999
•
LMEM is an internal memory in LU/XL ASIC chip. It has private and shared regions for
Packet Processing Engines. LMEM data errors are very rare events caused by
environmental factors (this is not created by software). Due to a software defect, an
error in the shared LMEM region will result in corruption of critical data structures of
Packet Processing Engines that causes unpredictable communication of LU/XL ASIC
chip with MQ/XM ASIC chip. These events will corrupt the state in MQ/XM and lead
to a MQ/XM wedge. The MQ/XM wedge would cause fabric blackhole and finally reboot
the line card. PR1082932
•
On MX Series routes with MPCs/MICs-based platform, the "RPF-loose-mode-discard"
feature is not working when configured within a Virtual Router routing instance. The
feature is working only when configured in the main instance. PR1084715
•
In Junos version 13.3R3, 14.1R1, 14.2R1, there is a new feature, an extra TLV term is added
to accommodate the default action for the "next-interface" when the corresponding
next-interface is down. While doing an ISSU from an image without the feature to an
image with this feature, all MPCs might crash. PR1085357
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
With MX Series router with FPC, Load balance hash seed will be changed after ISSU.
Since the hash seed value will be reverted to original value by rebooting FPC, there
would be hash value inconsistency in the system which might introduce blackholing
on multicast flavor traffic (mcast or BUM on vpls/l2-bridge). Affected versions. 12.3R7,
13.2R4-13.2R5, 13.3R2-13.3R3, 14.1R1, 14.1R3-14.1R4, 14.2R1-14.2R3. PR1086286
•
The prompt for SSH password changed in JUNOS 13.3, from "[email protected]'s password:"
to "Password:". This change breaks the logic in "JUNOS/Access/ssh.pm" which is
located in /usr/local/share/perl/5.18.2/ on Ubuntu Linux, for example. PR1088033
•
On MX platform with MPC/MIC or T4000 FPC5, TCP session with
MS-Interface/AMS-Interface configuration is not established successfully with the
"no-destination-port" or "no-source-port" configuration statements configured under
forwarding-options hierarchy level. PR1088501
•
When an interface on MQ-based FPC is going to link down state, in-flight packet on
interface transmit path will be stuck on the interface and never drained until the
interface comes up again. As a result, small number of such stacked packets will be
sent out when the interface is going to UP state. No other major impact should not be
seen after those packets are drained. PR1093569
•
On MX2020/2010 router, an SPMB core file will be seen if there are bad XF chips (fabric
chip) on SFB, which might trigger RE/CB switchover. PR1096455
•
On MX Series routes with MPCs/MICs, when the type of the IPv6 traffic is non-TCP or
non-UDP (for example, next header field is GRE or No Next Header for IPv6), if the
traffic rate is high (for instance, higher than 3.5Mpps), the packet re-ordering may
occur. PR1098776
•
On Trio-based line cards, when the prefix-length is modified from higher value to lower
value for an existing prefix-action, heap gets corrupted. Due to this corruption, the FPC
might crash anytime when further configurations are added/deleted. The following
operations might be considered as a workaround: Step 1. Delete the existing
prefix-action and commit Step 2. Then re-create the prefix-action with newer
prefix-length PR1098870
•
From Junos release 14.1 and above, IPv6 mobility packets with Heartbeat option that
the length of the mobility header (including the ethernet encapsulation and main IPv6
header) extends beyond 128 Bytes will be discarded as bad IPv6 option packet due to
a logic error in packet handling. PR1100442
Copyright © 2016, Juniper Networks, Inc.
167
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Routing Policy and Firewall Filters
•
In Class-of-Service (CoS) environment, there is a possibility (happened twice so far
and not reproducible in the lab) that routing protocol process (rpd) may crash due to
the CoS memory may get incorrectly freed and then allocated again. PR1062616
Routing Protocols
•
Deletion of a routing-instances may lead to a routing daemon crash. This may happen
if routing-instance's Routing Information Bases (RIB) is referenced in an active
policy-option configuration. As a workaround, when deactivating the routing-instance,
all associated configurations using the route-table names in the routing-instance
should also be deactivated. PR1057431
•
In Protocol Independent Multicast (PIM) sparse mode environment, in the situation
that the router is being used as the rendezvous point (RP) also the last hop router,
when the (*,G) entry is present on the RP and a discard multicast route (for example,
due to receiving multicast traffic from non-RPF interface) is already existed, if the (S,G)
entry is learnt after receiving source-active (SA) of the Multicast Source Discovery
Protocol (MSDP), the SPT cutover may fail to be triggered. There is no traffic impact
as receivers still can get the traffic due to (*,G) route. PR1073773
•
In mutli-topologies IS-IS scenario, there is huge difference between estimated free
bytes and actual free bytes when generating LSP with IPv6 Prefix. It might cause LSP
fragment exhaustion. PR1074891
•
In an MPLS L3VPN Core network, enable BGP Prefix-Independent Convergence (PIC)
Edge feature on a PE router, if the same VPN route is received with different multiple
exit discriminator (MED) via two route reflectors (RR), when BGP PIC evaluates those
two routes, it disregards the one with higher MED hence fails to build a multipath
protection/backup path entry. PR1079949
•
When removing scale BGP configuration, if the BGP session are holding stale routes
for the benefit of a restarting peer, the routing protocol process (rpd) may crash. As a
workaround, the administrator may use CLI command "show route receive-protocol
bgp <peer address> extensive | match STALE" to find the existing stale routes. If there
are none, then removing the BGP configuration may not cause the rpd crash. PR1081460
•
If a policy statement referred to a routing-table, but the corresponding routing instance
is not fully configured (ie. no instance-type), commit such configuration might cause
the rpd process to crash. PR1083257
•
With Multicast Source Discovery Protocol (MSDP) and nonstop active routing (NSR)
configured on the Protocol Independent Multicast (PIM) sparse-mode rendezvous
point (RP), the rpd process might permanently get stuck when multicast traffic received
shortly after Routing Engines switchover. PR1083385
•
When there are a number of secondary BGP routes in inet.0, an SNMP walk of inet.0
by the bgp4 MIB can cause a core if the corresponding primary routes are being deleted.
PR1083988
•
168
When BGP route is leaked to a routing-instance and there is an import policy to overwrite
the route preference, if damping is also configured in BGP, the BGP routes which were
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
copied to second table can't be deleted after routes were deleted in master table. This
is a day-1 issue. PR1090760
•
When removing BGP Prefix-Independent Convergence (PIC) from the configuration,
the expect behavior is that any protected path would become unprotected. But in this
case, the multipath entry that contains the protection path (which is supposed to be
removed) remains active, until BGP session flaps or the route itself flaps. As a
workaround, we can use "commit full" command to correct or to commit. PR1092049
•
In Junos OS Release 9.1 and later, RFC 4893 introduces two new optional transitive
BGP attributes, AS4_PATH and AS4_AGGREGATOR. These new attributes are used
to propagate 4-byte AS path information across BGP speakers that do not support
4-byte AS numbers. In this case, when AS4_AGGREGATOR attribute (18) is received
from a 2-byte AS peer (note AS4_AGGREGATOR attribute is only received when the
aggregator has 4-byte AS but this peer only supports 2-byte AS), NSR synchronization
with standby Routing Engine would fail, causing session constantly bouncing on standby
Routing Engine (hogging CPU). PR1093615
•
The rpd process might crash when resolve-vpn and rib inet.3 are configured under
separate levels (BGP global, group and peer). The fix is If anybody configures a family
at a lower level, reset the state created by either of knobs from higher levels. This
behavior conforms with our current behavior of family config - which is that any config
at a lower level is honored and the higher level config is reset. PR1094499
•
When BGP routes has multiple protocol nexthops including discard/reject and other
IGP nexthops, the discard/reject nexthop will be selected as BGP nexthop, which will
cause traffic loss. PR1096363
Services Applications
•
In IPsec environment, after performing the Routing Engine switchover (for example,
performing Graceful Routing Engine Switchover) or chassis reboot (that is, whole
device is powered down and powered UP again), due to the key management daemon
(kmd) may be launched before the Routing Engine mastership is finalized, it may stop
running on the new master Routing Engine. PR863413
•
The session-limit-per-prefix feature for the MX DSLITE server does not take Softwire
flow into account when calculating the the flow limit. PR1023439
•
On M/MX/T Series routers with Multiservices 100, Multiservices 400, or Multiservices
500 PICs with "dump-on-flow-control" configured, if prolonged flow control failure,
the coredump file might generate failure. PR1039340
•
On MX series routers which are acting as LNS to provide tunnel endpoints, it is observed
that the service-interfaces are not usable if an MIC corresponding to them is not
physically installed on the FPC. If only those service interfaces that belong to the
removed PIC are added to service-device-pool, this results in no LNS subscribers able
to login. Please note that once the MIC is inserted into the FPC, the features could be
used. PR1063024
•
Service PIC daemon (spd) might crash with core-dumps due to CGNAT pool's
snmp-trap-thresholds configuration. PR1070370
Copyright © 2016, Juniper Networks, Inc.
169
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Earlier output from "show service l2tp tunnel" will not display tunnels with no sessions.
This behavior have been changed, now empty tunnels are also displayed in this
command. PR1071923
•
In CG-NAT or statefull firewall environment, due to a null pointer check bug, the MS-DPC
might crash every few hours. Note that this is a regression issue. PR1079981
•
The crash happens if in a http flow, the flow structure is allocated at a particular memory
region. There is no workaround but the chances of hitting this issue are very low
PR1080749
•
On Layer 2 Tunnel Protocol (L2TP) network server (LNS), during L2TP session
establishment, when receiving Incoming-Call-Connected (ICCN) messages with Last
Sent LCP CONFREQ Attribute Value Pair (AVP) but without Initial Received LCP
CONFREQ and Last Received LCP CONFREQ AVPs, the jl2tpd process might crash.
PR1082673
•
In a L2TP tunnel-switching scenario, if a tunnel-switched tunnel is cleared with "clear
services l2tp tunnel peer-gateway" AND an incoming ICRQ is received simultaneously
from the LAC side destined for this tunnel-switched tunnel, this leads to jl2tpd crash.
This defect has now been rectified. PR1088355
•
On Trivial File Transfer Protocol (TFTP) Application Layer Gateway (ALG) with NAT
translation type "dynamic-nat44" configured, MS-DPC/MS-MPC/MS-MIC might crash
when processes the TFTP packets. PR1091179
•
On M series platform, in Layer 2 Tunneling Protocol (L2TP) network server (LNS)
environment, not all attributes (Missing NAS-Identifier, NAS-Port-Type, Service-Type,
Framed-Protocol attributes) within Accounting-Request packet are sending to the
RADIUS server. PR1095315
•
If MS-DPC is used in CG-NAT environment, in a very rare condition, when the MS-DPC
tries to delete a NAT mapping entry (e.g. entry timeout), error might occur and the
MS-DPC might get rebooted and then dump a core file. PR1095396
•
Some values of MIB object jnxSrcNatStatsEntry might be doubled when AMS (or rsp)
interface and NAT are configured together. PR1095713
VPNs
170
•
For VPLS over VPLS topology, when the VPLS payload has two labels
(Customer-VPLS-label and Customer-MPLS-label), the frame might be dropped by
the core facing interface hosted on IQ2 PIC with "L2 mismatch timeout" error. This
particular scenario is fixed. But there are some other worse scenarios which might hit
this issue again due to the system architecture limitation, which are not fixed but need
to avoid: * Addition of VLAN tags on Service provider's or CE's VPLS payload e.g.
configuring QinQ. * Addition of MPLS tags on Service provider or CE's VPLS payload.
* Enabling VPLS payload load balancing on Service provider's PE router. PR1038103
•
On a dual Routing Engine, if mvpn protocol itself is not configured, and non stop active
routing is enabled, the show command "show task replication" on master Routing
Engine will list MVPN protocol even though it is not configured. Other than the
misleading show output which may be slightly confusing to the user/customer, there
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
is no functional impact due to this issue as such. There is no workaround available.
PR1078305
Resolved Issues: 14.2R3
•
Class of Service (CoS) on page 171
•
Forwarding and Sampling on page 171
•
General Routing on page 172
•
Interfaces and Chassis on page 178
•
Layer 2 Features on page 180
•
MPLS on page 181
•
Network Management and Monitoring on page 182
•
Platform and Infrastructure on page 182
•
Routing Policy and Firewall Filters on page 185
•
Routing Protocols on page 185
•
Services Applications on page 186
•
Subscriber Access Management on page 187
•
VPNs on page 187
Class of Service (CoS)
•
For a ATM interface configured with hierarchical scheduling, when a
traffic-control-profile attached at ifd (physical interface) level and another output
traffic-control-profile at ifl (logical interface) level, flapping the interface might crash
the FPC. PR1000952
•
This error message "only per-unit and 2-level hierarchical scheduler are supported on
this interface" is a cosmetic regression issue without any functional impact. PR1050512
•
Forwarding class accounting feature might fail to function after FPC reboot. PR1060637
Forwarding and Sampling
•
When a firewall filter, which is used to de-encapsulate the IPv4 packets encapsulated
in IPv6 GRE header, is attached to interface hosts on MX Series routers with MPC/MIC,
the IPv6 GRE header would be de-encapsulated but the inner IPv4 packet would end
up getting dropped and not forwarded. This issue affects the packet with IPv4 over
IPv6 GRE header only, and those packets with IPv6 over IPv6 GRE header are not
affected. PR1054039
•
If the template of the policer is changed (for example, change the bandwidth-limit
value of policer), shared-bandwidth-policer knob may not function properly anymore.
PR1056098
Copyright © 2016, Juniper Networks, Inc.
171
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
General Routing
•
"show services accounting usage" does not populate cpu utilization for XLP-based
cards. Use "show services service-sets cpu-usage". PR864104
•
On MX Series platform with Enhanced DPCs equipped, After router rebooted, the IRB
broadcast channel is not enabled. All the broadcast packets that are received in the
IRB interface will get dropped. Also when ping is given the below L2Channel error
increases as ping packets are sent: [email protected]>show interfaces ge-*/*/* extensive
| match channel L3 incompletes: 0, L2 channel errors: 10, L2 mismatch timeouts: 0
PR876456
•
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 MS-PIC. The memory limit then might cause packets loss.
PR954079
•
The knob 'gratuitous-arp-on-ifup' should send a gratuitous arp on each unit of a physical
interface, but in Release 12.3 and later releases, only the first unit is seeing the configured
behavior. PR986262
•
In the dual Routing Engines scenario, in rare condition, while executing GRES and
deleting interfaces at the same time, it is possible that a nexthop delete message is
not sent to rpd process, causing rpd to keep a nexthop index (NHID) that kernel has
already deleted. Later when kernel allocates this NHID for next new nexthop and sends
it to rpd process, rpd process might crash due to duplicate NHID. PR987102
•
If a user configures an MX Series Virtual Chassis member with member ID 2, the Virtual
Chassi's master Routing Engine might eventually experience a kernel panic. PR989291
•
In Ethernet VPN (EVPN) integrated routing and bridging (IRB) deployment, when all
the access interfaces go down under an EVPN bridge domain, the IRB interface in the
bridge domain remains up causing the issue of the IRB subnet remaining being
advertised in L3 routing which in turn attracts all L3 VPN traffic for the subnet.
PR994909
172
•
In the dual Routing Engines scenario with NSR configuration, backup peer proxy thread
is hogging CPU for more than 1 second if there are multiple updates (>5000) going
from master Routing Engine to backup Routing Engine. This leads to FPC socket
disconnections. The traffic forwarding might be affected. PR996720
•
On MX104 router with SONET/SDH OC3/STM1 (Multi-Rate) MIC. In rare condition, if
the MIC is plugged out from MX104, the Packet Forwarding Engine might crash, the
traffic forwarding will be affected. These MICs as below belong to SONET/SDH
OC3/STM1 (Multi-Rate) MIC: * MIC-3D-8OC3OC12-4OC48 * MIC-3D-4OC3OC12-1OC48
* MIC-3D-8CHOC3-4CHOC12 * MIC-3D-4CHOC3-2CHOC12 * MIC-3D-8DS3-E3 *
MIC-3D-8CHDS3-E3-B * MIC-3D-1OC192-XFP PR997821
•
On MX Series platform with nonstop active routing (NSR) enabled, if with
switchover-on-routing-crash knob configured, issuing the CLI command "request
system core-dump routing fatal" might not trigger Routing Engine switchover and
might cause rpd on master Routing Engine stuck in inactive. PR1000220
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
If encapsulation type is "ppp" for the SONET interface on IQE PIC, sometimes the MTU
change might not work. PR1001880
•
An unnecessary update from the routing protocol process (rpd) to the route record
database might be triggered by a certain configuration change. This process causes a
jump in CPU utilization of all Packet Forwarding Engines. PR1002107
•
If the connection with an OpenFlow controller goes down then comes back up
repeatedly, an OpenFlow interface might send an OFPT_ERROR packet with an XID
ID 0 but no data to explain why the error packet was sent. PR1003538
•
On MX Series Virtual Chassis with the no-split-detection configured, in some rare
circumstances, the transit traffic might get dropped if all of the virtual chassis ports
(VCP) go down and come up quickly (within few seconds). PR1008508
•
On MX Series platforms with ADPC FPCs, M120 or M7i/M10i with Enhanced CFEB each
VPLS LSI interface flapping triggers a memory leak in jtree segment 0. There is no
memory leak in FPC heap 0 memory. PR1009985
•
If you issue the "show services nat mappings details" command with a large number
of service sets configured (such as 1000 service sets) and one or two NAT mappings
specified, the command takes a certain amount of time to display the output. During
this period, if you deactivate or activate the services, an MS-PIC management daemon
core file is generated. PR1019996
•
On MX Series routers with MS-MPC/MS-MIC, if the "dump-on-flow-control" knob is
configured, traffic loss and the mspmand process crash might be observed when the
MS-PIC comes up with traffic. PR1037086
•
If some groups have not been applied on a router, in some corner cases, the action that
load override configuration might cause the routing protocol process (rpd) to crash.
PR1037527
•
When the CPU usage is very high (e.g. 100%) on Routing Engine, the MS-MIC might
get stuck due to kernel deadlock, which triggers the card to crash and generate a core
file. PR1038026
•
The chassis daemon (chassisd) log file is filled by the following unimportant message.
These messages are repeated and will fill up from the chassisd log file. These messages
are harmless and are generated as part of fabric health check. fm_hsl2_is_pb_adpc:
jam_fabric: Not present in DB, key: fabric.lc.0x997.enable_grant_bypass
fm_hsl2_get_combination_blackhole_pbs: jam_fabric: Not present in DB, key:
fabric.lc.0x997.fabric_conct.supports_off_loading_xf PR1014594
•
On TXP with GRES enabled, when performing graceful switchover on all chassis (include
line-card chassis (LCC)) from master Routing Engine to backup Routing Engine, minimal
IPv4 traffic loss around 0.04% to 0.05% will be observed on aggregated 100GE PIC
on FPC type 4. PR1014420
•
If the service option configured on aggregated multiservices (AMS) interface is different
from its member interface, conflict would happen which might cause some serious
issue. After this fix, service-options configuration (which includes
timeouts/sessions-limit and so on) should only be configured on all members interfaces
when configure AMS bundle. PR1014898
Copyright © 2016, Juniper Networks, Inc.
173
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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
•
When destinations are pointing to protocol next-hops as unilist type or IP forwarding
next-hops as unilist, which in scenarios like using Loop-Free Alternate Routes for OSPF
(LFA-OSPF) with link protection or MPLS FRR is enabled. If flapping the active interface
very fast, especially an interface comes back up before Kernel gets a chance to delete
all the unilist next-hops, those unilist next-hops which have not been deleted yet would
be re-used. As a result, the corresponding destinations are pointing to discard
next-hop(s) or replaced next-hop(s) in Packet Forwarding Engine Jtree. The "discard"
next-hop(s) causes traffic blackhole while the "replaced" next-hop(s) diverts traffic
to other active next-hop(s) in the unlist. Those unilist next-hops which have been
already deleted are safe and get updated accordingly. This is a day one timing issue.
PR1016649
•
Under corner cases, if there are multiple back-to-back Virtual Chassis port (VCP)
related CLI commands, Network Processing Card (NPC) core may be observed and
FPC hosting the VC ports might reboot. PR1017901
•
During unified ISSU on MX-VC platform, there is a chance that the management process
(mgd) on both VC-M and VC-B consider itself as protocol backup, resulting in a reboot
of the entire VC. PR1020606
•
Trace file size is already limited to 1 megabytes, but the actual issue is different. When
a 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 a supported configuration. If
'forwarding-opions sampling sample-once' is subsequently deactivated the FPC may
reboot. PR1021946
•
MQCHIP(0) mqchip_get_q_forwarded_stats() invalid q_sys 0 q_num messages are
continously shows in logs.It will cause two GE or XGE interfaces can't farward traffic.
PR1021951
174
•
Permanent partial traffic loss seen after FPC restart+GRES with NSR. After FPC restart
(MPC 3D 16x 10GE) it is obsrved that fabric streams are programmed wrongly on
(MPC4E 3D 32XGE). that is why all traffic going from MPC 3D 16x 10GE->MPC4E 3D
32XGE is dropped. PR1026214
•
The host MPC might continuously crash when trying to online a faulty MS-MIC after
discovering the hardware failure. PR1026310.
•
Configuring a routing policy with the "no-route-localize" option to ensure that the
routes matching a specified filter are installed on the FIB-remote Packet Forwarding
Engines, after removing the routing policy and changing the next-hop for the routes,
the previously installed routes using "no-route-localize" policy might not get removed
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
from some Packet Forwarding Engines. Then the Packet Forwarding Engines will not
forward received packets to the FIB-local Packet Forwarding Engines to perform full
IP table lookup but use the staled routes instead. PR1027106
•
On MPC5E line card, if a firewall filter with large-scale terms (more than 1300) is
attached to an interface, traffic drop might be seen. PR1027516
•
In a rare case, rdd core is reported under /usr/sbin/rdd as soon as applying the group
and commit is performed. PR1029810
•
On MX Series platform with MS-MPC card, after performing switchover from master
RE0 to backup RE1, 2 internal ARP entries for Routing Engine address (128.0.0.1) on
MS-MPC PICs pointing to two eth interfaces connect to CB0 and CB1 separately might
be wrongly created. Then if pull out RE0/CB0, the MS-PIC would still select the eth
interface connects to CB0, which results in loss of connectivity because that path is
not available anymore. PR1030119
•
PCS statistics counter is now displayed for MX 100GE interfces in below command:
cli > monitor interface <intf> PR1030819
•
In the scenario where router acts as both egress LSP for core network and BRAS for
subscribers, RSVP-TE sends PathErr to ingress router due to matching to subscriber
interfaces wrongly when checking the explicit route object (ERO), if subscribers are
associated with same lo0 address as used by RSVP LSP egress address. PR1031513
•
With an unrecognized or unsupported Control Board (CB), mismatch link speed might
be seen between fabric and FPCs, which results in FPCs CRC/destination errors and
fabric planes offline. Second issue is in a race condition, Fabric Manager (FM) might
process the stale destination disable event but the error is cleared indeed, it will result
in the unnecessary FPC offline and not allowing Fabric Hardening action to trigger and
recover. PR1031561
•
This issue only affects OC-48 MICs. If an SFP is inserted into an OC-48 MIC port that
has been disabled the SFP will not show up in a >show chassis hardware command.
The issue is fixed with a patch. Contact JTAC to find out which version is best for you.
PR1031851
•
The Software Development Kit (SDK) Service process (ssd), which runs on the Routing
Engine and is responsible for communications between the SDK application and Junos
OS, might crash after Routing Engine switchover and following reboot of both Routing
Engines. Since the ssd acts as the broker daemon for Applications connecting to Juniper
distributed application framework (JDAF) services, the applications will lose JDAF
connectivity when ssd restarts. PR1031860
•
With VPLS BGP control word configured, intermittent packet loss might be seen in one
direction on VPLS circuit due to the control-word not being programmed at Packet
Forwarding Engine after member DPC reboot. The problem can happen on below
conditions: 1. LSI interface exists across two or more physical interfaces. 2. Those
physical interfaces located in different FPCs. 3. Those physical interfaces consist of
equal-cost paths. So, LSI will not be flapped with one member FPC down. 4. Flap the
member DPC where one of physical interfaces situated. PR1031863
•
In rare cases, the AUTHD daemon may crash and cause a corruption of subscriber
dynamic profiles. In-use profiles may be incorrectly marked as not in use. Any subscribers
Copyright © 2016, Juniper Networks, Inc.
175
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
that reference that profile are forced to remain in Terminating state, until the router is
rebooted. Daemon restarts and GRES switches are ineffective in working around this
situation. PR1032548
176
•
Problem scenario: Issue is seen only with VMX. It will be seen when the PPPoE session's
Keep-alive timer expiry happens. This might be due to non-graceful termination of
remote side or due to communication path failure with the remote end. Problem
statement: When PPPoE session Keep-alive timer expires the local PPPoE session is
NOT closed/logout. PR1034520
•
If an IFL is used as the qualified-next-hop (which implies the IFL has
unnumbered-address configured), and there are changes in the IFL filter configuration,
then the static route might disappear from routing table. To make it reappear, need to
delete it from the configuration and add it back. PR1035598
•
Somtimes AE vlan ifl output byte counters are shown as large value and it is a generic
issue. PR1036813
•
Using jnxoptIfOTNPMFECIntervalTable and jnxOpticsPMIntervalTable it is not possible
to walk these tables from the middle before this fix. PR1039030
•
In a subscriber scenario with auto-sensed VLAN configured, after scaled subscribers
(in this case, 16K subscribers) login/logout for several times, the subscriber management
process might stuck and not able to restart due to a Session Database (SDB) deadlock
issue. PR1041094
•
For MLPPP interface on Trio based line card, in some very rare conditions, the received
fragmented packets might be dropped. PR1041412
•
On T series routers running Junos OS release 12.1 or later, for interface connected via
optical system like DWDM, when the interface is admin disabled, there might be a
delay (300-400msec) for system to detect the event and during which time, traffic
blackhole might be seen. Please note if disable the interface by breaking the Rx or Tx
link, issue will not happen. PR1043762
•
Incorrect SNMP interface index (index 0) is given to VCP interface. Due to wrong index
value, VCP interface description does not appear in SNMP interface table. PR1044331
•
On MX Series routers with one of the following protocols configuration, flapping the
protocols will trigger the Composite Next-hop change operation. In rare condition,
since it is not proper programmed, the FPC might crash. This is a day-1 issue. - LDP MPLS - Point-to-multipoint LSP - RSVP - Static LSPs PR1045794
•
Once default route 0.0.0.0/0 is added, deleted or changed, the PFEMAN thread running
on the MPC/FPC5 needs more than 600msec to program such changes. This is long
enough to trigger LFM or BFD flap. Junos OS Release 13.3R2 or later is exposed to this
symptom. PR1045828
•
For T Series routers, the unilist next-hop member will become 'replaced' status on
Packet Forwarding Engine after interface flapping with ARP timeout. While the problem
is happening, routing-table will display all right next-hop status but can not forward
traffic since forwarding next-hop in Packet Forwarding Engine is in 'replaced' status
and no longer active. PR1046778
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On T series FPC 1-3 and M320 except E3-FPC with fib-local configuration. If there are
multiple FIB local FPCs or the FIB local is a multiple Packet Forwarding Engine FPC,
the TCP packets might out of order, packets re-ordering would occur. It reduces the
application level throughput for any protocols running over TCP. PR1049613
•
In the PPP dual-stack subscribers environment, in rare condition, if bringing up 1000
dual-stack subscribers quickly, the PPP negotiation might fail. Then PPP retries
negotiation, all subscribers fully establish. PR1050415
•
Incorrect flow count is reported in the field 'count' of V9 header in all the packets sent
to the collector. PR1050543
•
This problem is because of a race condition, where other FPCs are not able to drain
"which is 1 second" Fabric Streams connecting to FPC which is getting offline. With
this situation - even when FPC comes online, other FPCs which have observed message
"xmchip_dstat_stream_wait_to_drain" will not able to send traffic to that particular
FPC over fabric. There is no workaround. Rebooting FPCs which observed error message
"xmchip_dstat_stream_wait_to_drain" is a recovery. PR1052472
•
In subscriber management environment, the Berkeley Database (DB) may get into
deadlock state. It is brought on by multiple daemons attempting to simultaneously
access or update the same subscriber or service record. In this case, due to the access
to DB were blocked by device control daemon (dcd), the subscriber management
infrastructure daemon (smid) fails to recover the DB. Consequently, the router may
stop responding to all the login/logout request as well as statistics activity. This timing
related issue is most likely to occur during login or logout and when the system is busy.
PR1054292
•
VCP links do not stay up during ISSU. This causes traffic loss, and control plane packet
loss which can lead to control protocol flaps. PR1054344
•
In subscriber management scenario, when dynamic VLAN (DVLAN) demux interface
configured on MX series router, the interface may get in stuck state, it could be observed
that the statistics of demux0 may stop incrementing. This is because Session Database
(SDB) may incorrectly calculate the number of subscriber over DVLANs. When the
issue occurs, for example, the router may not able to process any PPPoE Active
Discovery Initiation (PADI) packet, and fail to establish the PPPoE session. PR1054914
•
OpenSSL project has published a security advisory for vulnerabilities resolved in the
OpenSSL library on January 8th 2015: CVE-2014-3569, CVE-2014-3570, CVE-2014-3572,
CVE-2014-8275, CVE-2015-0204, CVE-2015-0205. Refer to JSA10679 for more
information. PR1055295
•
In IPv6 environment, after enabling feature "solicit-router-advertisement-unicast", the
IPv6 router may fail to reply the Router Advertisement (RA) to the IPv6 host as unicast
only. To be exactly, the IPv6 router may not only reply to the IPv6 host a RA as unicast
to its link local address, but also send the RA as multicast to all nodes group (Multicast
Address: ff02::1). The sample configuration could be found as below: [email protected]>
show configuration protocols router-advertisement interface ge-1/0/3.400 { ...
solicit-router-advertisement-unicast; <<<<< "solicit-router-advertisement-unicast"
feature is enabled ... } PR1056599
Copyright © 2016, Juniper Networks, Inc.
177
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
IFCM error messages may occur in logs when it is not used. We lowered the severity of
the message to avoid confusion. PR1057712
•
In LDP tunneling over single hop RSVP based LSP environment, after enabling
"chained-composite-next-hop", the router may fail to create the chained composite
next hops if the label value of VPN is equal with the label value of LDP. PR1058146
•
On MX Series routers, the interrupt-driven link down detection might stop working.
When the line card is receiving multiple back-to-back faults in very short duration (no
matter from remote or local), it might fail to detect all the received interrupts, and this
failure might cause delay of the link down detection. PR1060279
•
When enabling pseudowire subscribers the "show subscribers extensive" command
does not display CoS policies applied to the subscriber interface. PR1060036
•
Due to incomplete fix, in releases containing PR869773 fix, rate limit drops are seen
for Ingress queuing even though rate-limit is not configured or supported for ingress.
PR1061256
•
If Bidirectional Forwarding Detection (BFD) protocol is enabled via site-to-site IPsec
tunnel, the BFD session may fail to come up. It is because, when the BFD protocol is
trying to exchange the packet via IPsec tunnel, the value of the TTL in inner IP header
for packet may be decremented, hence the BFD packet gets dropped on the peer side
and no BFD session would come up. PR1061342
•
On MX Series router, after performing in-service software upgrade (ISSU) to
14.2R1/14.1X50-D40 and above release, the clock synchronization might be stuck to
"freerun" and Enhanced SCB (SCBE) clocking interface might appear as down.
PR1065308
Interfaces and Chassis
178
•
REG_ERR errors might be observed on MX-router with Enhanced SCBs and mix of MPC
and DPC cards. PR821742
•
Ether OAM on DPC 10ge interface module changed link-fault status from down to up
after being changed link status to down by "asynchronous-notification". PR973840
•
On MX Series routers, CFM sessions over AE interfaces, whose child links are on DPC
FPC can be scaled to a maximum of 300. PR1020222
•
if DPCE 20x 1GE + 2x 10GE X card is present in the chassis, BFD sessions over AE
interfaces may not be distributed. PR1032604
•
Some duplicate entries are reported in jnx-chas-defines.mib. This patch removes the
duplicate entries to fix the issue. PR1036026
•
On Ethernet PICs with longer hold down timer configured, flapping interface within the
hold time might cause traffic loss longer than the hold period. PR1040229
•
In case of the IQ2 or IQ2E PIC are working in tunnel-only mode, rebooting the tunnel
PIC while the traffic is passing through the tunnel might cause the tunnel PIC to not
transfer traffic any more. PR1041811
•
clear interfaces interface-set statistics all fails due to memory limitation PR1045683
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On MX Series routers with Enhanced Switch Control Board (SCBE), when the fan tray
is inserted or pulled out, the chassisd process might crash. PR1048021
•
When configuring the Virtual Router Redundancy Protocol (VRRP) on an interface
which is included in a routing-instance via applying groups setting, if changes are made
to the interface, the VRRP process (vrrpd) memory leak might be observed on the
device. PR1049007
•
dcd is cored by configuring IPv6 address on fxp0.0 with master-only option under
interfaces configuration. PR1049450
•
When Inherit is part of lower IFL Unit, VRRPD parses it before Active. In this case, VRRPD
attaches a dummy Active to the Inherit, with the assumption that the Active will be
available soon and then replication of information from Active to Inherit will take place.
However, the replication of the priority was not done correctly due to which the Inherit
group was stuck with priority of 0. PR1051135
•
Two redundant logical tunnels (rlt) interfaces are configured with knob
"per-unit-mac-disable" enabled. After configure the second one, the first rlt interface
goes down. rlt0 { logical-tunnel-options { per-unit-mac-disable; <<<<<< } } PR1055005
•
The CLI description of the new 100-Gigabit Metro DWDM OTN PIC
(PTX-2-100G-WDM-M) is different from the existing 100-Gigabit DWDM OTN PIC
(P1-PTX-2-100G-WDM). The 100-Gigabit Metro DWDM OTN PIC's transceiver is
identified as OTN-100G-M in the output from the show chassis hardware CLI command
and the cable type is identified as 100G METRO in the output from the show chassis
pic CLI command. PR1055325
•
After performing a unified in-service software upgrade (ISSU) on MX Series Virtual
Chassis (MX-VC) platform, all physical interfaces may go down. And the interfaces
remain down until a graceful Routing Engine switchover (GRES) is performed.
PR1055327
•
When a dynamic PPPoE subscriber with targeted-distribution is configured on a dynamic
vlan demux interface over aggregated Ethernet, the device control daemon (dcd)
process might crash during a commit if the vlan demux has mistakenly been removed.
The end users cannot use the Internet after the crash. This is a rare issue and not easy
to be reproduced. PR1056675
•
In subscriber management environment, PPP client process (jpppd) might crash as a
result of a memory allocation problem. PR1056893
•
In multichassis link aggregation groups (MC-LAGs) environment, the MC-LAG peers
have the MAC and port information and can forward the traffic appropriately. If a single
VLAN is modified to a different VLAN, and then the administrator rolls back the VLAN
configuration to the original one, the remote MAC might be stuck in the "Pending" state
and not be installed in the bridge MAC-table, which cause the traffic forwarding being
affected. PR1059453
•
For Multichassis link aggregation groups (MC-LAGs) running in active-active mode
with back-to-back square topology, when the Interchassis Control Protocol (ICCP) is
broken between any MC-LAG devices, the non preferred device reverts to its own local
system ID. But its Link Aggregation Control Protocol (LACP) partner on the remote
Copyright © 2016, Juniper Networks, Inc.
179
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
side does not remove the flap link from AE bundle and it remians UP. This might cause
a network wide loop resulting in traffic outage until manual intervention. PR1061460
•
After chassis restart or non-graceful Routing Engine switchover, a few vrrp sessions
might start sending vrrp packets while still in vrrp backup state. PR1062929
•
Error message is continuously logged every second after a particular copper-SFP
[P/N:740-013111] is plugged into a disabled port on MIC. ***** error message ****
mic_sfp_phy_program_phy: ge-*/*/* - Fail to init PHY link mic_periodic_raw: MIC(*/*)
- Error in PHY periodic function PQ3_IIC(WR): no target ack on byte 0 (wait spins 2)
PQ3_IIC(WR): I/O error (i2c_stat=0xa3, i2c_ctl[1]=0xb0, bus_addr=0x56)
mic_i2c_reg_set - write fails with bus 86 reg 29 mic_sfp_phy_write:MIC(*/*) - Failed to
write SFP PHY link 0, loc 29 mic_sfp_phy_mdio_sgmii_lnk_op: Failed to write: ifd = 140
ge-*/*/*, phy_addr: 0, phy_reg: 29 ala88e1111_reg_write: Failed (20) to write register:
phy_addr 0x0, reg 0x1d Fails in function ala88e1111_link_init PR1066951
Layer 2 Features
•
If a customer is using SNMP and performs an snmpwalk on the dhcp binding table, all
of the entries might not be displayed. This fix resolves that issue so that bindings for
all IP addresses are displayed. PR1033158
•
In DHCP dynamic subscriber management scenario, when maintain DHCP subscribers
during interface delete is configured, some interface indices might be reused by a new
interface if system is under stress (such as high connection speed, many clients and
individual log files configured to be larger than 100M). In this case, it might result in
subscriber being associated with an interface that no longer exists. PR1044002
•
If the ppmd does not send replies to lacpd's periodic request to gather port statistics,
the lacpd process may crash and restart due to the process memory consumption
being slowly increased and finally reaching RLIMIT_DATA value which is 128MB.
PR1045004
•
LDP-VPLS with BGP autodiscovery stays down after GRES event when NSR is enabled.
PR1046887
180
•
On multiple Routing Engines system with NSR enabled, if the FEC129 VPLS instance
has "no-tunnel-service" configured, the VPLS might show status as "OL" (no outgoing
label) after performing Routing Engine switchover. PR1050744
•
After changing the way of getting the site ID of VPLS from fixed site-id to
automatic-site-id on one site while other sites are still using the fixed site-id in the
network, the rpd process might crash due to the site ID get by "automatic-site-id" may
conflict to site ID which was configured as fixed site ID on other sites. PR1054985
•
The Layer 2 Control Protocol process (l2cpd) leaks memory when interface config is
applied to LLDP-enabled interfaces using 'apply-groups'. Size of the leak is ~700 bytes
per commit. PR1052846
•
When MX Series router acts as the Virtual Extensible Local Area Network (VXLAN)
Layer 3 gateway, the integrated routing and bridging (IRB) interfaces are configured
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
to connect the VXLANs. The VXLAN Packets are dropped when the route to reach a
remote virtual tunnel endpoint (VTEP) interface is over an IRB interface. PR1057005
•
After FPC rebooted, the filter under Packet Forwarding Engine of ERPS brigde domain
might program the incorrect ifl index, it will cause router can't receive any ERPS packets.
PR1070791
MPLS
•
Error "tag_icmp_route:failed to find a chain composite ahead of fwd nh" might be
observed when doing traceroute. PR999034
•
On the P2MP LSP transit router with link protection enabled, if the LSP is the last
subLSP, tearing the last subLSP (for example, a RESV tear message is received from
downstream router) might crash the routing protocol process (rpd). PR1036452
•
After upgrading to Junos OS Release 13.2 or later from previous releases, logical-system
cannot start and run. The rpd continuously crashes every time when try to
deactivate/activate the logical-system. PR1044781
•
When node-protection is enabled for a specified LSP and optimize-timer for a
node-protecting bypass LSP is configured on router, the bypass route might
get-optimized in such a way that it traverses through the very node that the bypass is
trying to protect during re-optimization. As a consequence, the node-protecting bypass
LSP only provide link protection instead of node protection. PR1045055
•
In NG-MVPN extranet scenario, if there is a mix of VT interfaces and LSI (vrf-table-lable
is used) interface on NG-MVPN egress node, after changing some vrf policies, the
routing protocol process (rpd) might crash and reset. PR1045523
•
In LDP link protection which is protected by dynamic RSVP LSP scenario, when flap
the interface having LDP link-protection enabled, the rpd process might crash on
backup Routing Engine as soon as the bypass LSP is established. PR1053426
•
On M/MX/T Series routers, dynamic-rsvp-lsp is configured under interface
link-protection hierarchy level. After interface flap, the bypass LSP does not come up.
PR1054155
•
With graceful-restart configured, an inter-domain point-to-multipoint (P2MP) label
switched path (LSP) with ERO defined and CSPF enabled might fail to come up after
rpd process restart. PR1058271
•
This is a regression issue on all Junos operating systems related to a timing factor.
When LDP session flaps, over which entropy label TLV or any unknown TLV is received,
the LDP speaker might not send label withdraw for some prefixes to some neighbors.
As a result, these neighbors will still use stale labels for the affected prefixes. PR1062727
•
LDP session going down because of Entropy Label Capability (ELC) TLV encoded in
label mapping message. PR1065338
•
Bypass enabled with optimize-timer will flap during every re-optimization event.
PR1066794
•
Bypass LSP does not come up within the expected time. PR1072781
Copyright © 2016, Juniper Networks, Inc.
181
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Network Management and Monitoring
•
If the size of the interface control process (dcd) trace file is configured to large (for
example, 500M), restarting the dcd process when it is doing log rotation (due to size
limit reached) might cause dcd process to be unable to start any more. At the same
time, interface ports will be down and "thrashing" error will be seen. PR1047330
•
SNMP mib walk jnxMac does not return value with et- interfaces on
MPC3/MPC4/MPC5/MPC6. PR1051960
•
There is no specific counter name in the MIB2D_COUNTER_DECREASING syslog
message. PR1061225
•
SNMP queries for LAG MIB tables while LAG child interface is flapping, might cause
mib2d to grow in size and eventually crash with a core file. Mib2d will restart and recover
by itself. PR1062177
Platform and Infrastructure
182
•
With inline jflow enabled, if the low 12 bits of the packet counter are zero (0x000)
while copying packets count from hash record into flow export packet, the
packetDeltaCount counter might be incorrect in inline jflow records. There is no traffic
impact but may impact billing. PR886222
•
Filter from wrong routing-instance being used for BFD packets. PR993882
•
BFD sessions within default routing-instance are not coming up once inline-services
pic is configured and fixed class-of-service forwarding-class is assigned. BFD sessions
operating in no-delegate-processing are not affected. PR999647
•
CPQ RLDRAM ECC single and double bit error will generate CM alarm. "show chassis
alarms" command can be used to view CM alarm. Details ======= 1> CPQ RLDRAM
ECC single bit error in last 10 secs will raise minor CM alarm. 2> No CPQ RLDRAM ECC
single bit error in last 10 secs will clear minor CM alarm. 3> CPQ RLDRAM ECC double
bit error will raise Major CM alarm (this alarm will not be cleared until the FPC is
restarted) PR1023146
•
On MX platform with scaled set-up, after deactivate/activate or renaming a bridge
domain (BD) which has irb interface associated, the IGMP snooping configured under
the BD might not work any more. Please note it happens only when the router is in
"network-services enhanced-ip" mode. PR1024613
•
A Packet Forwarding Engine memory leak is seen when multicast receivers are
connected in a bridge domain where IGMP snooping is enabled and IGMP messages
exchanged between the multicast receivers and the layer 3 IRB (Integrated Routing
and Bridging) interface. PR1027473
•
Inline BFD sessions, through AE interface when only member interface of the AE is
hosted on MX MPC4E line card, might flap continuously. PR1029341
•
On MX Series routers with MPC, when there is a congested Packet Forwarding Engine
destination, the non-congested Packet Forwarding Engine destinations might experience
an unexpected packet drop. PR1033071
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
The micro BFD sessions will not come up if incoming untagged micro BFD packets
contain a source MAC where the last 12 bits are zero. PR1035295
•
configuration.yang had posix regex pattern while as per YANG rfc, it should have been
xml regex, thus it had compilation issues. Now it is fixed PR1040151
•
When an IRB interface is configured with VRRP in Layer 2 VPLS/bridge-domain, in
corner cases, the IRB interface might not respond to an ARP request targeting to IRB
sub-interface IP address. PR1043571
•
In a scaled subscriber management environment, the output of CLI command "show
subscribers" and its sub flavors might print more pages and has to be terminated by
"Ctrl+c" or "q". But this was not closing the back end Session Database (SDB)
connection properly. Over a period of time, this will cause inconsistency and the
subscriber management infrastructure daemon (smid) fails to register and no new
subscribers could connect. PR1045820
•
On T4000 and FPC Type 5-3D or TXP-3D platforms , BFD sessions operating in
100msec interval with default multiplier of 3 might randomly flap after the
enhancements implemented via PR967013. BFD sessions with lower intervals of
100msec or higher intervals are not exposed. The internal FPC thread, monitoring the
High Speed Fabric links had a run time of longer then 100msec. PR1047229
•
On MX Series platform with Extensible Subscriber Services Management (ESSM)
subscribers configured using Junos OS commit script, after performing sequence of
operations repeatedly with same set of configuration (subscribers apply-macros'),
like adding subscribers, then deleting same subscribers again, then adding, then deleting
again and again like so, the memory would leak on mgd process. In a generic scenario
where a script just commits transient change and then exits, the issue will not be
experienced. PR1048770
•
By default, after 16x10GE MPCs come up about 75 percent of queues were allocated
to support rich queuing with MQ chip. Such allocation causes MQ driver software
module to poll stats. Polling stats causes this rise in CPU usage. PR1048947
•
For a Routing Matrix, if different Routing Engine models are used on switch-card chassis
(SCC)/switch-fabric chassis (SFC) and line-card chassis (LCC) (for example, RE-1600
on SCC/SFC and RE-DUO-C1800 on LCC), where the out-of-band (OoB) management
interfaces are named differently (for example, fxp0 on SCC/SFC RE and em0 on LCC
RE), then the OoB management interface configuration for LCC RE will not be
propagated from SCC/SFC RE during commit. PR1050743
•
NTP.org has published a security advisory for multiple vulnerabilities resolved in ntpd
(NTP daemon) that have been assigned four CVE IDs. Junos has been confirmed to
be vulnerable to one of the buffer overflow vulnerabilities assigned CVE-2014-9295
which may allow remote unauthenticated attackers to execute code with the privileges
of ntpd or cause a denial of service condition. Refer to JSA10663 for more information.
PR1051815
•
After committing the Network Time Protocol (NTP) configuration, if the number of
routing-instances per source-address exceeds 18, it may cause NTP daemon (ntpd)
crash. In this scenario, the NTP feature may not be functional. For example there are
19 routing-instance names per source address statement in the sample configuration
Copyright © 2016, Juniper Networks, Inc.
183
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
below. ntp { server X.X.X.X; source-address X.X.X.X routing-instance [ X1 X2 X3 X4 X5
X6 X7 X8 X9 X10 X11 X12 X13 X14 X15 X16 X17 X18 X19 ]; (19 routing-instance names) }
PR1058614
•
On an MX Series router with MPCS/MICs with Junos 12.3R3 and above, the system does
not push the configured Tag Protocol ID (TPID) value (for instance, 0x88a8) to the
packets while sending out the packets, instead it pushes default TPID 0x8100. This
might lead to traffic drop on the peer device if it is expecting a particular TPID (for
instance, 0x88a8) whereas it receives a different one. PR1059225
•
Modifying IEEE-802.1ad rewrite-rule on the fly might unable to change IEEE-802.1p
ToS values for inner VLAN in QinQ. PR1062817
•
On MX Series routers, the observation domain ID in exported flow records is incorrect
in Hyperion100G and 10G line cards and in 200G 40x10G MPCs. PR1066319
•
On MX Series routers with MPCs and T4000 routers with Type 5 FPCs, the feature
"enhanced-hash-key" is configured to select data used in the hash key for enhanced
IP forwarding engines. If "type-of-service" is configured at the [edit forwarding-options
enhanced-hash-key family inet] hierarchy level, or "traffic-class" is configured at the
[edit forwarding-options enhanced-hash-key family inet6] hierarchy level, the last
significant 2 bits of the TOS/TC bytes under the IPv4/IPv6 header are extracted
incorrectly as load sharing input parameters, this might cause unexpected load
balancing result. PR1066751
•
Firewall filters which have a prefix-action can't be configured under [edit logical-system
<name> firewall family inet] because the Packet Forwarding Engine won't be
programmed for the filter. PR1067482
•
OMemory leak within the Packet Forwarding Engine once inline sampling is active.
PR1071289
184
•
VPLS filter applied under forwarding-options might drop VPLS frame unexpected
when it's coming from an lt- interface. There is no workaround. PR1071340
•
When inline-sampling is enabled, in race conditions, if packet gets corrupted and the
corrupted packet length shows 0, which may cause "PPE_x Errors thread timeout error"
and eventually cause MPC card to crash. PR1072136
•
After IPv6 RPM(real-time performance monitor) support, snmp server cannot recieve
some of IPv6 PING-MIB info. For example, snmp server receives "pingCtlRowStatus(23)"
and "pingCtlAdminStatus(8)" error and cannot get "pingResultsTable" and
"pingProbeHistoryTable" info. << example >> ** The following logs are snmp server
logs. "snmpset -v 2c -c xxxxxx" commands are used. ----pingCtlRowStatus(23) error
info. Error in packet. Reason: inconsistentValue (The set value is illegal or unsupported
in some way) Failed object:
SNMPv2-SMI::mib-2.80.1.2.1.23.7.79.87.78.69.82.95.65.6.84.69.83.84.95.65
---pingCtlAdminStatus(8) error info. Error in packet. Reason: inconsistentValue (The
set value is illegal or unsupported in some way) Failed object:
SNMPv2-SMI::mib-2.80.1.2.1.8.7.79.87.78.69.82.95.65.6.84.69.83.84.95.65 ** The
following logs are snmp server logs. "snmpwalk -v 2c -c xxxxxx" commands are used.
pingResultsTable(3) SNMPv2-SMI::mib-2.80.1.3 = No Such Object available on this
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
agent at this OID pingProbeHistoryTable(4) SNMPv2-SMI::mib-2.80.1.4 = No Such
Object available on this agent at this OID PR1072320
Routing Policy and Firewall Filters
•
RIP route in vrf getting removed once rib-groups are applied with import policy.
PR1024946
•
In the BGP environment, if operator "!" exists in the regex for as-path, the commit
operation failure. PR1040719
•
When configuring the unsupported IPv6 flow specification feature, that is, when
configuring inet6 address as source/destination of inet-flow route, the configuration
can pass the commit check and be committed. But it can cause the rpd process crash
eventually when trying to program this route to firewall process (dfwd, which manages
compilation and downloading of Junos OS firewall filters). If a flow route is received
from a BGP neighbor and the prefix-length for source/destination is greater than 32,
it can lead to an rpd process crash too. PR1059542
Routing Protocols
•
If with BGP PIC edge feature enabled and OSPF protocol as IGP, when the primary
route changed, there is a chance that the Packet Forwarding Engine forwarding entry
will stay in reroute state which causes session down. PR1015598
•
When BGP add-path feature is enabled on BGP route-reflector (RR) router, and if the
RR router has mix of add-path receive-enabled client and add-path receive-disabled
(which is default) client, due to a timing issue, the rpd process on RR might crash when
routes update/withdraw. PR1024813
•
When a BGP peer goes down, the route for this peer should be withdrawn. If it happens
that an enqueued BGP route update for this peer has not been sent out, issuing the
CLI command "show route advertising-protocol bgp <peer-addr>" might crash the
routing protocol process (rpd). This is a very corner issue and hardly to be experienced.
PR1028390
•
If labeled BGP routes are leaked from inet.3 table to inet.0, then activation of BGP
"add-path" feature might crash the routing protocol process (rpd). PR1044221
•
BFD session might reset on commit if version is configured. The adaptive RX interval
gets set to 0 which results in the reset. A sample configuration of BFD version is as
following: protocols { bgp { bfd-liveness-detection { version 1; minimum-interval 1000;
transmit-interval { minimum-interval 1000; } } } PR1045037
•
When BGP and ICCP are the client of the same multi-hop BFD session, BFD runs in
centralized (non-distributed) mode. But if nonstop-routing configuration is added and
enabled, runing mode of BFD is changed to distributed mode. This behavior is incorrect
but it would not affect to protocols which is client of the BFD session. However, if
Routing Engine switchover is performed after enabling NSR, the BFD session will get
unstable and all the client protocols also get unstable. PR1046755
•
On MX Series router with multiple Routing Engines, if an aggregate Ethernet (AE)
interface spreads over multiple FPCs, the inline BFD session over the interface might
flap during GRES. PR1048940
Copyright © 2016, Juniper Networks, Inc.
185
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The Junos OS Multicast Source Discovery Protocol (MSDP) implementation is closing
an established MSDP session and underlying TCP session on reception of source-active
TLV from the peer when this source-active TLV have an "Entry Count" field of zero.
"Entry Count" is a field within SA message which defines how many source/group
tuples are present within SA message. PR1052381
•
The secondary routes of BGP in the inet.3 routing table that are still being used may
get deleted prematurely. PR1052884
•
After deactivating/deleting BFD configuration, Packet Forwarding Engine receives BFD
session down event and it marks corresponding nexthops as down and traffic drops
consequently. PR1053016
•
The BGP session sending add-path prefixes can cause an rpd crash when the add-path
IDs that it allocates roll over from 65535 to 0. If the routes contributing add-path
prefixes are changing, the allocated path-id can eventually reach this value. This fix
changes the allocation scheme to always use the lowest available free path-id, so a
rollover will never occur. PR1053339
•
After multicast traffic source incoming interface and source ip RPF (reverse path
forwarding) route switching to a different interface, the multicast route cache upstream
interface might not be refreshed to be in sync with the pim join upstream interface.
This is incorrect and will cause packet blackhole for the affected multicast stream.
PR1057023
•
BGP LINK STATE (BGP-LS) was using unofficial code point of '99' for LINK-STATE
path attribute. Starting with Junos OS Release 14.2R3, BGP-LS uses IANA-assigned
value of '29'. Therefore, previous versions of BGP-LS are not compatible with the code
point change. Also, if the user was already running BGP-LS, they cannot do ISSU to
this version of the code. PR1060162
•
When running Simple Network Management Protocol (SNMP) polling to specific ISIS
Management Information Base (MIB) with invalid variable, it will cause routing protocol
process (rpd) crash. PR1060485
•
In PIM environment, Bootstrap Router (BSR) can be used only between PIMv2 enabled
devices. When deactivating all the interfaces which are running PIM bootstrap, the
system changes to operate in PIMv1. At this time, all the information learnt about/from
the current BSR should be cleaned, but actually, BSR state is not cleaned. If the interface
which was the previous “elected BSR” is activated, BSR state is
PIM_BSR_ELECTED(should be cleaned previously) and the system assumes the BSR
timer is still here. When the system tries to access the null BSR timer, the rpd process
might crash. PR1062133
•
Allow the last 2byte AS, 65535, to be used as local-as and peer-as, but it will be
considered private in all other regards. PR1069307
Services Applications
186
•
The show cli command "service nat pool detail" always displays the Port range starting
from 1024 even when privileged ports are used. PR1019783
•
Added support to bring up Tunnel-switched sessions when tunnel-group is not
configured at LTS and tunnel attributes are returned from RADIUS. PR1030799
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
When NAT has multiple terms that refer to the same NAT Pool, the command 'show
snmp mib walk jnxSvcsMibRoot ascii' always prints out jnxNatPoolTransHits for the
count of jnxNatRuleTransHits in the first term. PR1035635
•
When using both Port Control Protocol (PCP) and traditional NAT (for example,
DS-Lite), if you try to set up two pools with overlapping address ranges, this can lead
to MS-DPC to crash and generate a core file. PR1036459
•
In the context of DS-Lite softwire scenario, the MS-PIC/MS-DPC might crash in rare
occasions when the DS-Lite softwire concentrator is receiving a high volume of outer
IPv6 fragmented packets. PR1044143
•
Inline IPv6 L2TP on MPC subscriber terminated at a LNS breaks adaptive services SP
unicast nexthops on MS-DPC. Even one subscriber causes the issue. PR1054589
•
When the tunnel between the L2TP access concentrator (LAC) and L2TP network
server (LNS) is destroyed, the tunnel information will be maintained until
destruct-timeout expires (if the destruct-timeout is not configured, the default value
is 300 seconds). If the same tunnel is restarted within the destruct-timeout expiry, the
LNS will use the previously negotiated non default UDP port, which might lead to tunnel
negotiation failure. PR1060310
•
A Layer 2 Tunneling Protocol daemon (l2tpd) crash is seen sometimes when the L2TP
service interface unit number is configured higher than 8192. A restriction has been
added to force unit numbers below 8192. PR1062947
•
When configuring RADIUS authentication for Layer 2 Tunneling Protocol (L2TP), the
RADIUS server cannot be recognized because the source address is not being read
correctly. As a result, the L2TP session cannot be established. PR1064817
•
L2TP daemon will core in LTS scenario while the subscriber logs out. This happens
when the subscriber has "Called Number AVP" attribute. The "Called Number AVP"
was not getting relayed correctly across LTS boundary, hence daemon cores.
PR1065002
Subscriber Access Management
•
This issue was introduced as part of another fix. Contact JTAC for the recommended
release for your deployment. PR1049955
VPNs
•
On MX-VC platform, if with a scaled number of MVPN routes, after adding a new
interface in the MVPN instance or changing the traceoptions related configuration, the
CPU on the Routing Engine might experience a high utilization for about 10minutes.
PR1027596
•
In NG MVPN, after the route to C-RP flaps, traffic loss might be seen for a short period
of time. PR1049294
•
In NG-MVPN scenario with the non-zero selective provider tunnel threshold-rate
configured and NSR enabled, the selective provider tunnel might flap a few seconds
after Routing Engine switchover. The, related Type 3 S-PMSI AD route and Type 4 leaf
AD route also refreshed. The data traffic might fall to inclusive provider tunnel in a
Copyright © 2016, Juniper Networks, Inc.
187
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
short time depending on the configuration. This transition will cause packet loss due
to unbinding from one tunnel to the other and back. PR1049352
•
In the VPLS environment with a multichassis link aggregation groups (MC-LAGs)
configuration, the standby neighbor is configured with hot-standby mode. If the active
link on MC-LAG members facing towards CE is changed continually (that is active to
standby and standby to active), in rare condition, the traffic might not shift correctly,
and the rpd process might crash. PR1050737
•
In NG-MVPN scenario, when a source is directly connected to a PE router that is acting
as an RP stops sending the traffic, the PE routrt never withdraws the Type 5 route. This
causes the Type 7 routes and forwarding routes to remain on the egress and ingress
PEs. PR1051799
•
In L2VPN scenario with local switching enabled, in corner cases, the rpd process might
crash after flapping the PE-CE link. For example, if the L2VPN connection type changes
from remote to local after link flaps, for a brief period of time, two route entries (for
old remote VC connection and for the new local VC connection) might exist for the
same egress route (with interface name as destination prefix). In that case, when
deleting remote VC connection and route entry associated with that remote connection,
the rpd might crash due to trying to reset an internal variable which is already reset
during route addition for the new local VC connection. PR1053887
•
In the l2circuit environment, when l2ckt configuration has backup-neighbor, the
flow-label operation is blocked at the configuration level. PR1056777
•
With a static selective point-to-multipoint LSP configured for an MBGP MVPN, when
sending Type 3 S-PMSI A-D BGP route, the Juniper Networks implementation uses the
values taken from the selective P-Tunnel configuration, which is not compliant with
RFC standard. Refer to RFC 6514 section 4.3 which specifies that the source and group
length values in Type-3 must be same as the host prefix length. That is, if the Multicast
Source field contains an IPv4 address, then the value of the Multicast Source Length
field is 32; if the Multicast Source field contains an IPv6 address, then the value of the
Multicast Source Length field is 128. The same is true for group length. PR1058193
•
In MVPN RPT-SPT mode, with a mix of local and remote receivers all using (*,g) joins
(spt-threshold infinity), the downstream interfaces may not get updated properly and
there may be a stuck (s,g) forwarding route. This issue can occur with the following
sequence of events: 1. Local receivers are joined 2. Traffic starts, then stops, and the
route times out. 3. Remote receiver joins. Both a (*,g) and an (s,g) forwarding route
are created. 4. Another local receiver is joined, or an existing one is pruned. 5. In the
(*,g) route the downstream interface list reflects the update, but in the (s,g) route the
downstream interface list does not. 6. When traffic starts again, the (s,g) route -- which
has the wrong interface list -- is used. The traffic flows to the wrong set of receivers.
PR1061501
Resolved Issues: 14.2R2
188
•
Class of Service (CoS) on page 189
•
Interfaces and Chassis on page 189
•
Layer 2 Features on page 190
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
MPLS on page 190
•
Platform and Infrastructure on page 191
Class of Service (CoS)
•
This issue specific to rate-limit on trunk port in DPC due to a software issue that
installing rate-limit variables to egress Packet Forwarding Engine doesn't work normally.
PR1022966
•
For ichip based platform, IQ2 pic expects FC index in the cookie from ichip for packet
queuing. For Transit traffic, fc index is coming in cookie where are for host outbound
traffic, queue number is coming in cookie to IQ2 pic. As IQ2 pic is not aware whether
traffic is transit or host outbound, it treats value received in cookie as FC value and
looks into fc_to_q table to fetch queue number. This is causing issue in queueing of
host outbound traffic in IQ2 PIC in incorrect queue. This is a day one issue and will come
if in FC to Queue mapping, fc id and queue number are not same. PR1033572
Interfaces and Chassis
•
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 ISSU. This behavior is being further analyzed and fixed
in further releases. PR1015895
•
On 10GE interface on MIC (e.g. 3D 4x 10GE XFP and 3D 2x 10GE XFP MIC), when
"link-down" event under "optics-options alarm low-light-alarm" is configured and the
"hold-time down" timer is set greater than 0, the status of the interface will remain
up, even when the light power exceed low alarm threshold and traffic being interrupted.
PR1018076
•
VRRP daemon (vrrpd) memory leak might be observed in "show system processes
extensive" when VRRP is set with routing-instance and then change any configuration.
PR1022400
•
With vrf-table-label configured on the routing-instances, when a FPC with Enhanced
IQ (IQE) PIC is sharing the same Forwarding Engine Forwarding Engine Board (FEB)
with another FPC, and the FEB has two core-facing interfaces configured with the
family mpls on aforementioned FPCs separately, the Label-Switched Interface (LSI)
interfaces might be removed incorrectly on the working FPC when the other FPC with
IQE PIC is set to offline. PR1027034
•
"set forwarding-options enhanced-hash-key symmetric" knob will not get applied on
MX104 Packet Forwarding Engine. PR1028931
•
With heartbeat connection for an MX Series Virtual Chassis (MX-VC) enabled, if the
heartbeat connection detects that the Virtual Chassis master router (VC-M) is still
operating and able to respond during a split caused by a failure of all the Virtual Chassis
port (VCP) interfaces, the Virtual Chassis backup router (VC-B) should go offline after
the heartbeat timeout period expires. But VC-B retains VC backup role and never go
offline although its FPCs went into PRESENT state. In addition to fix the deviation from
the expected functionality, the output of CLI command "show virtual-chassis heartbeat
[detail]" is enhanced to more clearly indicate the successful detection of the peer
Copyright © 2016, Juniper Networks, Inc.
189
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MX-VC member chassis over the heartbeat connection when the chassis loses all VCP
adjacency links. A unique "detected" state is provided when MX-VC splits and last
heartbeat pulse response is successfully received. PR1034096
•
Configuring ODU FRR on 2x100G DWDM under otn-options could result in a FPC core.
PR1038551
•
FRR switching time is much higher than 50ms (e.g. might be 400-900 ms) when
protected links are located on MX gigabit ethernet enhanced and hardened MICs
(i.e.MIC model name end with -E or -EH, currently, the supported MICs are
MIC-3D-20GE-SFP-E and MIC-3D-20GE-SFP-EH). PR1038999
•
For ethernet OAM/CFM, if Maintenance-association (MA) ICC format name of length
less than 13 characters (13 byte) is used, deactivate/activate of ?protocol oam? may
cause CFM operation failures. 'Cross-connect CCM received? alarm will be seen. There
can be other triggers also. ITU CARRIER CODE format uses fix length size for MA NAME
(13 octets). JUNOS creates and maintains actual size configured by user. However the
length it maintains is 13 octets. For lower size MA name the value accessed is not
deterministic. It would work fine if the subsequent memory is initialized to zero. Else
would declare cross connect error as the accessed MA name will be different compared
to remote end. PR1041482
Layer 2 Features
•
In a mixed VPLS instance where both LDP and BGP flavors are present with "best-site"
knob configured under "site" block, any cli change in that instance will result in rpd
crash. PR1025885
MPLS
190
•
TED link information of protocol from highest credibility level is used irrespective of
the level at which CSPF is computing. i.e., cspf-metric in "show mpls lsp extensive"
would have the sum of te-metric of IGP with highest credibility at each hop in ERO.
This has been corrected and the cspf-metric will be sum of te-metric of current
credibility at each hop. PR1021593
•
When RSVP label-switched-path (LSP) optimize is enabled, RSVP LSP might stay
down after a graceful Routing Engine mastership switchover (GRES). To resolve the
problem, the corresponding label-switched-path configuration needs to be deactivated,
then, be activated again. PR1025413
•
When configuring point-to-multipoint (P2MP) Label Distribution Protocol (LDP)
label-switched paths (LSPs), the labels will never be freed even they are no longer
needed. This could lead to the MPLS label exhaustion eventually. To clear the state,
the rpd process will restart with core dumps. PR1032061
•
When a LDP enabled router receives a LDP label mapping message which includes an
unknown TLVs with unknown and forward bit set, the unknown TLV will be re-advertised
along with the LDP message to upstream LSR. However, due to merge issue, Junos
appends these unknown TLVs multiple times during construction of label mapping
message and will has a unknown TLV(0x0000) with length 0 among the appended
unknown TLVs, thereby causing the LDP session with the peer that receives this
message flapping. PR1037917
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Platform and Infrastructure
•
With inline jflow enabled, when the flow is exported once and got reinserted, if the low
12 bits of the packet counter are zero (0x000), the packetDeltaCount counter might
be incorrect in inline jflow records. There is no traffic impact but may impact billing.
PR886222
•
The non-first IP fragments containing UDP payload may be mistakenly interpreted as
PTP packets if the following conditions are met: - the byte at the offset 9 in the IP
packet contains 0x11 (decimal 17) - UDP payload - the two bytes at the offset 22 in the
IP packet contain the value 0x01 0x3f (decimal 319; byte 22=0x01 and byte 23=0x3f)
- PTP protocol The mis-identification of the packet as PTP will trigger the corruption
of the fragment payload. PR1006718
•
The fix was committed for this PR# but it also needs DDOS configuration additional
to this fix and it is as below: 1) check the "show ddos-protection protocols statistics
terse" 2) For each of the Control plane protocols on the system like ospf/vrrp/pvstp,
it is recommended to configure 2X of the rate as give below example along with
increasing DDOS rate for virtual-chassis control. Example, ######## set system
ddos-protection protocols virtual-chassis control-high bandwidth 20000 set system
ddos-protection protocols virtual-chassis control-high burst 20000 set system
ddos-protection protocols ospf aggregate bandwidth 1000 set system ddos-protection
protocols ospf aggregate burst 1000 set system ddos-protection protocols vrrp
aggregate bandwidth 100 set system ddos-protection protocols vrrp aggregate burst
100 PR1017640
•
On Trio based platform, with igmp-snooping enabled and a multicast route with
integrated routing and bridging (IRB) as a downstream interface, a multicast composite
nexthop is created with a list of L3 and corresponding L2 nexthops. In a rare corner
case, the corresponding L2 nexthop to the L3 IRB nexthop is a DISCARD nexthop and
will cause the FPC to crash. PR1026124
•
When receiving traffic coming on MPC and going out on DPC, an Ethernet frame with
known DMAC will be flooded to the whole bridge domain after flapping the link which
the given MAC is learnt for more than 32 times. PR1026879
•
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
•
On ICHIP line-card, when the packets are queued for several seconds due to interface
congestion and get aged, the ICHIP might not able to detect those aged packets and
thus fail to drain the queue out, which results in the FPC showing CRC errors and going
into wedge condition. PR1028769
•
Trio-based line card might crash when trying to install the composite next-hop used
for the next-hop-group configuration related to port mirroring of traffic over IRB to an
LSI attached to VPLS instance for a remote host. PR1029070
•
When the 'enhanced-hash-key services-loadbalancing' feature is used by Trio based
line cards, load balancing of flows across multiple service PICs via the source-address
across does not work when internal BGP (IBGP) is used to steer traffic to the inside
Copyright © 2016, Juniper Networks, Inc.
191
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
service-interface. For example the operator will see on the stateful firewall that the
same source-address has flows across multiple service interfaces. PR1034770
Related
Documentation
•
The priority code point (PCP) and drop eligible indicator (DEI) bit in 802.1Q header are
preserved while packet gets routed within the same Packet Forwarding Engine. The
expected behavior is resetting the PCP and DEI bit when the packet is routed. PR1036756
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Documentation Updates
This section lists the errata and changes in Junos OS Release 14.2R6 documentation for
the M Series, MX Series, and T Series.
•
Adaptive Services Interfaces Feature Guide for Routing Devices on page 192
•
Broadband Subscriber VLANs and Interfaces Feature Guide on page 194
•
High Availability Feature Guide for Routing Devices on page 194
•
Monitoring, Sampling, and Collection Services Interfaces Feature Guide for Routing
Devices on page 194
•
MPLS Applications Feature Guide for Routing Devices on page 195
•
Overview for Routing Devices on page 196
•
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide for Routing
Devices on page 196
•
Services Interfaces Configuration Guide on page 196
•
Subscriber Access Protocols Feature Guide on page 196
•
Subscriber Management Access Network Guide on page 197
•
Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing
Devices on page 198
•
Tunnel and Encryption Services Interfaces Feature Guide for Routing Devices on page 198
•
User Access and Authorization Feature Guide for Routing Devices on page 198
•
VPNs Library for Routing Devices on page 199
Adaptive Services Interfaces Feature Guide for Routing Devices
•
192
The following items describe updates for aggregated multiservices (AMS) interfaces
information:
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
•
The description for the rejoin-timeout statement under the hierarchy [edit interfaces
interface-name load-balancing-options member-failure-options drop-member-traffic]
should be changed to the following:
Configure the time by when failed members (members in the DISCARD state) should
rejoin the aggregated multiservices (AMS) interface automatically. All members
that do not rejoin by the configured time are moved to the INACTIVE state, and the
traffic meant for each of the members is dropped.
If multiple members fail around the same time, then they are held in the DISCARD
state using a single timer. When the timer expires, all the failed members move to
INACTIVE state at the same time.
•
The following information should be added to the “Aggregated Multiservices
Interface” section in the “Understanding Aggregated Multiservices Interfaces” topic:
Member interfaces are identified as mams in the configuration. The chassisd process
in routers that support AMS configuration creates a mams entry for every multiservices
interface on the router.
When you configure services-options at the ams interface level, the options apply to
all member interfaces (mams) for the ams interface.
The options also apply to service sets configured on ms- interfaces corresponding
to the ams interface’s member interfaces. All settings are per PIC. For example,
session-limit applies per member and not at an aggregate level.
NOTE: You cannot configure services-options at both the ams
(aggregate) and member-interface level. If services-options is configured
on ms-x/y/z, it also applies to service sets on mams-x/y/z.
When you want services-options settings to apply uniformly to all
members, configure services-options at the ams interface level. If you
need different settings for individual members (for example, because of
a syslog configuration), configure services-options at the
member-interface level.
•
The show interfaces load-balancing command topic should include the following
description for Last change in the table:
Time elapsed since the last change to the interface. Changes that affect the elapsed
time displayed include internal events that might not have changed the state of any
member.
•
The “Configuring Secured Port Block Allocation,” “port,” and
“secured-port-block-allocation” topics should include the following note:
If you make any configuration changes to a NAT pool that has secured port block
allocation configured, you must delete the existing NAT address pool, wait at least 5
seconds, and then configure a new NAT address pool. We also strongly recommend
that you perform this procedure if you make any changes to the NAT pool configuration,
even if you do not have secured port block allocation configured.
Copyright © 2016, Juniper Networks, Inc.
193
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Broadband Subscriber VLANs and Interfaces Feature Guide
•
The table in topic “AAA Access Messages and Supported RADIUS Attributes and Juniper
Networks VSAs for Junos OS,” incorrectly indicates that VSA 26-1 (Virtual-Router)
supports CoA Request messages. VSA 26-1 does not support CoA Request messages.
•
The show subscribers topic in the Broadband Subscriber VLANs and Interfaces Feature
Guide does not fully describe the vlan-id vlan-id option. This option displays information
about active subscribers using a VLAN where the VLAN tag matches the specified
VLAN ID. The topic fails to mention that these subscriber VLANs can be either
single-tagged or double-tagged. The command output includes information about
subscribers using double-tagged VLANs when the inner VLAN tag matches the specified
VLAN ID. The command output does not distinguish between these two types of
subscribers.
To display only subscribers where the specified value matches only double-tagged
VLANs, use the stacked-vlan-id stacked-vlan-id option to match the outer VLAN tag
instead of the vlan-id vlan-id option.
High Availability Feature Guide for Routing Devices
•
The "Nonstop Active Routing System Requirements" topic should include the inet-mvpn
and inet6-mvpn protocol families for BGP in the list of supported family types. The
topic previously documented that NSR supports next-generation MVPN starting with
Junos OS 14.1R1, but didn't include the specific names of the next-generation MVPN
protocol families in the list.
•
The topic “Improving the Convergence Time for VRRP” failed to include the following
information:
•
Disable duplication address detection for IPv6 interfaces—Duplicate address
detection is a feature of the Neighbor Discovery Protocol for IPv6. Duplicate address
detection is enabled by default and determines whether an address is already in use
by another node. When duplicate address detection is enabled, convergence time
is high after an IPv6 interface that has been configured for VRRP tracking comes up.
To disable duplicate address detection, include the ipv6-duplicate-addr-translation
transmits 0 statement at the [edit system internet-options] hierarchy level. To disable
duplicate address detection only for a specific interface, include the dad-disable
statement at the [edit interfaces interface-name unit logical-unit-number family inet6]
hierarchy level.
Monitoring, Sampling, and Collection Services Interfaces Feature Guide for Routing
Devices
•
The Options section for the flow-export-rate statement under the hierarchy [edit
forwarding-options sampling instance instance-name family inet output inline-jlow] did
not include the default value. The default value is:
Default: 1 for each Packet Forwarding Engine on the FPC to which the sampling instance
is applied.
194
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
•
The default value for the ipv6-flow-table-size statement at the [edit chassis fpc
slot-number inline-services ipv6 flow-table-size] hierarchy level should state the
following:
“If the number of units is not specified, 1024 flow entries are allocated for IPv6.”
•
The description for the max-packets-per-second, maximum-packet-length, and
run-length statements at the [edit forwarding-options sampling instance instance-name
input] hierarchy level failed to include the following:
NOTE: This statement is not supported when you configure inline flow
monitoring (by including the inline-jflow statement at the [edit
forwarding-options sampling instance instance-name family (inet | inet6)
output] hierarchy level).
MPLS Applications Feature Guide for Routing Devices
•
The "Configuring Miscellaneous LDP Properties," "Configuring the Authentication Key
Update Mechanism for BGP and LDP Routing Protocols," "authentication-key-chain
(LDP)," and "authentication-key-chain (BGP and BMP)” topics should include the
following information: You must also configure the authentication algorithm using the
authentication-algorithm algorithm statement. This statement must be included at the
[edit protocols (bgp | ldp)] hierarchy level when you configure the
authentication-key-chain key-chain statement at the [edit protocols (bgp | ldp)] hierarchy
level.
•
The "Path Computation for LSPs on an Overloaded Router" topic should state that
when you set the overload bit on a router running IS-IS, only new LSPs are prevented
from transiting through the router. Any existing Constrained Path Shortest First (CPSF)
LSPs remain active and continue to transit through the router. The documentation
incorrectly states that any existing LSPs transiting through the router are also rerouted
when you configure the overload bit on an IS-IS router.
Copyright © 2016, Juniper Networks, Inc.
195
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Overview for Routing Devices
•
The "Configuring Automatic Mirroring of the CompactFlash Card on the Hard Disk
Drive" and the "mirror-flash-on-disk" topics should not include support for MX5, MX10,
and MX40 3D Universal Edge Routers. On the MX Series, this feature is supported only
on the MX104, MX240, MX480, MX960, MX2010, and MX2020 routers.
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide for Routing
Devices
•
The table in the “Firewall Filter Nonterminating Actions” topic failed to mention that
Juniper Networks recommends you do not use the nonterminating firewall filter action
next-hop-group with the port-mirror-instance or port-mirror action in the same firewall
filter.
Services Interfaces Configuration Guide
•
The following information regarding the restriction on prefix lengths that can be
configured in NAT pools on MS-MPCs and MS-MICs applies to the "Configuring Source
and Destination Addresses Network Address Translation Overview " section of the
"Network Address Translation Rules Overiew" topic:
On MX Series routers with MS-MPCs and MS-MICs, if you configure a NAT address
pool with a prefix length that is equal to or greater than /16, the PIC does not contain
sufficient memory to provision the configured pool. Also, memory utilization problems
might occur if you attempt to configure many pools whose combined total IP addresses
exceed /16. In such circumstances, a system logging message is generated stating that
the NAT pool name has failed to be created and that the service set is not activated.
On MS-MPCs and MS-MICs, you must not configure NAT pools with prefix lengths
greater than /16.
Subscriber Access Protocols Feature Guide
196
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
•
The LAC Tunnel Selection Overview, Configuring Weighted Load Balancing for LAC Tunnel
Sessions and weighted-load-balancing (L2TP LAC) topics in the Junos OS Broadband
Subscriber Management and Services libraries incorrectly describe how weighted load
balancing works on an L2TP LAC. The topics state that the tunnel with the highest
weight (highest session limit) within a preference level is selected until it has reached
its maximum sessions limit, and then the tunnel with the next higher weight is selected,
and so on.
In fact, when weighted load balancing is configured, tunnels are selected randomly
within a preference level, but the distribution of selected tunnels is related to their
weight. The LAC generates a random number within a range equal to the aggregate
total of all session limits for all tunnels in the preference level. Portions of the
range—pools of numbers—are associated with the tunnels according to their weight;
a higher weight results in a larger pool. The random number is more likely to be in a
larger pool, so a tunnel with a higher weight (larger pool) is more likely to be selected
than a tunnel with a lower weight (smaller pool).
For example, consider a level that has only two tunnels, A and B. Tunnel A has a
maximum sessions limit of 1000 and tunnel B has a limit of 2000 sessions, resulting
in an aggregate total of 3000 sessions. The LAC generates a random number in the
range from 0 through 2999. A pool of 1000 numbers, the portion of the range from 0
through 999, is associated with tunnel A. A pool of 2000 numbers, the portion of the
range from 1000 through 2999, is associated with tunnel B. If the generated number
is less than 1000, then tunnel A is selected, even though it has a lower weight than
tunnel B. If the generated number is 1000 or larger, then tunnel B is selected. Because
the pool of possible generated numbers for tunnel B (2000) is twice that for tunnel A
(1000), tunnel B is, on average, selected twice as often as tunnel A.
Subscriber Management Access Network Guide
Copyright © 2016, Juniper Networks, Inc.
197
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The LAC Tunnel Selection Overview, Configuring Weighted Load Balancing for LAC Tunnel
Sessions and weighted-load-balancing (L2TP LAC) topics in the Junos OS Broadband
Subscriber Management and Services libraries incorrectly describe how weighted load
balancing works on an L2TP LAC. The topics state that the tunnel with the highest
weight (highest session limit) within a preference level is selected until it has reached
its maximum sessions limit, and then the tunnel with the next higher weight is selected,
and so on.
In fact, when weighted load balancing is configured, tunnels are selected randomly
within a preference level, but the distribution of selected tunnels is related to their
weight. The LAC generates a random number within a range equal to the aggregate
total of all session limits for all tunnels in the preference level. Portions of the
range—pools of numbers—are associated with the tunnels according to their weight;
a higher weight results in a larger pool. The random number is more likely to be in a
larger pool, so a tunnel with a higher weight (larger pool) is more likely to be selected
than a tunnel with a lower weight (smaller pool).
For example, consider a level that has only two tunnels, A and B. Tunnel A has a
maximum sessions limit of 1000 and tunnel B has a limit of 2000 sessions, resulting
in an aggregate total of 3000 sessions. The LAC generates a random number in the
range from 0 through 2999. A pool of 1000 numbers, the portion of the range from 0
through 999, is associated with tunnel A. A pool of 2000 numbers, the portion of the
range from 1000 through 2999, is associated with tunnel B. If the generated number
is less than 1000, then tunnel A is selected, even though it has a lower weight than
tunnel B. If the generated number is 1000 or larger, then tunnel B is selected. Because
the pool of possible generated numbers for tunnel B (2000) is twice that for tunnel A
(1000), tunnel B is, on average, selected twice as often as tunnel A.
Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing Devices
•
The enhanced-hash-key configuration statement topic fails to mention that the
src-prefix-len option is available for configuration at the [edit forwarding-options
enhanced-hash-key family inet6 layer-3-services src-prefix-len] hierarchy level. You can
use the src-prefix-len option to include the source prefix length in the hash key for
enhanced IP forwarding engines.
Tunnel and Encryption Services Interfaces Feature Guide for Routing Devices
•
The “Configuring Unicast Tunnels” topic incorrectly shows the backup-destination
statement. This statement does not apply to unicast tunnels.
User Access and Authorization Feature Guide for Routing Devices
198
•
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.
•
The "Example: DHCP Complete Configuration" and "dchp" topics should not include
support for the MX Series Universal Edge 3D Routers. This feature is supported only
on the M Series and the T Series.
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
VPNs Library for Routing Devices
•
The “Routing Instances Overview” topic should include the following instance types:
Ethernet VPN (EVPN) and Internet Multicast over MPLS. Use the Ehternet VPN instance
type, which is supported on the MX Series only, to connect a group of dispersed
customer sites using a Layer 2 virtual bridge. Use the Internet Multicast over MPLS
instance type to provide support for ingress replication provider tunnels to carry IP
multicast data between routers through an MPLS cloud, using MBGP or next-generation
MVPN.
To configure an EVPN instance type, include the evpn statement at the [edit
routing-instances routing-instance-name instance-type] hierarchy level. To configure
an Internet Multicast over MPLS instance type, include the mpls-internet-multicast
statement at the [edit routing-instances routing-instance-name instance-type] hierarchy
level.
Related
Documentation
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Migration, Upgrade, and Downgrade Instructions on page 199
•
Product Compatibility on page 209
Migration, Upgrade, and Downgrade Instructions
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.
•
Basic Procedure for Upgrading to Release 14.2 on page 200
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 202
•
Upgrading a Router with Redundant Routing Engines on page 202
•
Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS
Release 10.1 on page 203
•
Upgrading the Software for a Routing Matrix on page 204
•
Upgrading Using Unified ISSU on page 205
•
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and
NSR on page 206
•
Downgrading from Release 14.2 on page 207
•
Changes Planned for Future Releases on page 207
Copyright © 2016, Juniper Networks, Inc.
199
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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:
[email protected]> 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.
200
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
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:
[email protected]> request system software add validate reboot
source/jinstall-14.2R6.9-domestic-signed.tgz
All other customers, use the following command:
[email protected]> request system software add validate reboot
source/jinstall-14.2R6.9-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.
•
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)
Copyright © 2016, Juniper Networks, Inc.
201
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 11.4, 12.3, and 13.3 are EEOL releases. You can upgrade from Junos OS
Release 11.4 to Release 12.3 or even from Junos OS Release 11.4 to Release 13.3. 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 12.1
(a non-EEOL release) to Junos OS Release 13.3 or directly downgrade from Junos OS
Release 13.3 to Junos OS Release 12.1.
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.
202
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
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.
Copyright © 2016, Juniper Networks, Inc.
203
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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:
204
•
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
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
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.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
(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
CAUTION: This release introduces some behavior changes to the unified
in-service software upgrade (ISSU) functionality for M, MX, and T Series
routers. We recommend that you not use unified ISSU to upgrade from an
earlier Junos OS release to Junos OS 14.2.
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
Copyright © 2016, Juniper Networks, Inc.
205
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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]
[email protected]# deactivate protocols pim
[email protected]# 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.
206
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
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]
[email protected]# set protocols pim nonstop-routing disable
[email protected]# activate protocols pim
[email protected]# 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:
•
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
Copyright © 2016, Juniper Networks, Inc.
207
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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 Release 15.1—The all keyword is optional. When you
type any of these clear commands followed by the ? in the CLI, the all keyword is 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 ?, the following possible completions are displayed:
[email protected]> 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 is mandatory. When you type a
clear command followed by the ? in the CLI, the <[Enter]> option to execute the
command directly (without specifying any options) is not available.
For example, when you type clear mpls lsp ?, you see all listed as an option but not
<[Enter]> to execute the command directly. You have to type clear mpls lsp all and
then press <[Enter]> if you want to clear information about all the nontransit or egress
LSPs originating on the router.
[email protected]> 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
208
•
New and Changed Features on page 59
Copyright © 2016, Juniper Networks, Inc.
Product Compatibility
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Product Compatibility on page 209
Product Compatibility
•
Software Compatibility on page 209
•
Hardware Compatibility on page 209
Software Compatibility
The Juniper Networks implementation of OVSDB on MX Series routers is supported with
the following VMware NSX versions:
•
Starting with Junos OS Release 14.2R1, NSX version 4.0.3.
•
Starting with Junos OS Release 14.2R2, NSX version 4.2 and later versions.
The Juniper Networks implementation of OVSDB on MX Series routers supports the
following OVSDB schema for physical devices versions:
•
Starting with Junos OS Release 14.2R1, OVSDB schema version 1.11.90 is compatible
with NSX version 4.0.3.
•
Starting with Junos OS Release 14.2R4, OVSDB schema version 1.3.0 is compatible
with NSX version 4.0.3 and with NSX version 4.2 and later.
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 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:
http://pathfinder.juniper.net/feature-explorer/
Related
Documentation
•
New and Changed Features on page 59
•
Changes in Behavior and Syntax on page 95
•
Known Behavior on page 106
•
Known Issues on page 109
•
Documentation Updates on page 192
•
Migration, Upgrade, and Downgrade Instructions on page 199
Copyright © 2016, Juniper Networks, Inc.
209
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Junos OS Release Notes for PTX Series Packet Transport Routers
These release notes accompany Junos OS Release 14.2R6 for the PTX 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 http://www.juniper.net/techpubs/software/junos/.
CAUTION: This release introduces some behavior changes to the unified
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 Release 14.2.
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Resolved Issues on page 222
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R6 for the PTX Series.
210
•
Hardware on page 211
•
Class of Service (CoS) on page 212
•
Interfaces and Chassis on page 212
•
Management on page 215
•
MPLS on page 215
•
Multicast on page 215
•
Network Management and Monitoring on page 215
•
Routing Policy and Firewall Filters on page 216
•
Routing Protocols on page 217
•
Software Installation and Upgrade on page 217
•
User Interface and Configuration on page 217
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.]
•
CFP-100GBASE-ZR (PTX Series)—In Junos OS Release 13.3R6, 14.1R4, 14.2R3, and
15.1R1 and later, the CFP-100GBASE-ZR transceiver provides advanced dual
Copyright © 2016, Juniper Networks, Inc.
211
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
polarization-quadrature phase shift keying (DP-QPSK) coherent digital signal processing
(DSP) and forward error correction (FEC)-enabled robust tolerance to optical
impairments and supports 80 km reach over single-mode fiber. The transceiver is not
specified as part of IEEE 802.3, but is built according to Juniper Networks specifications.
The following interface module supports the CFP-100GBASE-ZR transceiver:
•
100-Gigabit Ethernet PIC with CFP (P1-PTX-2-100GE-CFP)
For more information about the interface modules, see the “Cables and Connectors”
section in the PTX Series Interface Module Reference.
[See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications and Supported
Network Interface Standards by Transceiver for PTX Series Routers.]
Class of Service (CoS)
•
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.]
•
Change in scaling number for rewrite rules (PTX Series)—Starting in Junos OS Release
14.2R4, the scaling number for a rewrite rule is reduced by one when the default EXP
rewrite is used. This change in scaling number is introduced to:
•
Support all possible combinations of EXP rewrite rules.
•
Fix the issue of incorrect modification of EXP bits of the inner label by the default
MPLS EXP rewrite rule during the label pop operation.
[See CoS Features and Limitations on PTX Series Routers.]
Interfaces and Chassis
•
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.]
•
212
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,
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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
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.]
•
Unified ISSU support on FPC2-PTX-P1A FPC and P2-100GE-CFP2 PIC
(PTX5000)—Starting with Junos OS Release 14.2R2, unified in-service software
Copyright © 2016, Juniper Networks, Inc.
213
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
upgrade (ISSU) is supported on the FPC2-PTX-P1A FPC and on the P2-100GE-CFP2
PIC in PTX5000 routers. Unified ISSU enables you to upgrade from an earlier Junos
OS release to a later one with no disruption on the control plane and with minimal
disruption of traffic.
•
Support for dual-rate speed (PTX Series)—Starting in Junos OS Release 13.3R3, 14.1R3,
14.2R2, and later for PTX3000, and Junos OS 14.2R2 and later for PTX5000, support
for dual rate for the 24-port 10-Gigabit Ethernet PIC (P1-PTX-24-10GE-SFPP) enables
you to switch all port speeds to either 1-Gigabit Ethernet or 10-Gigabit Ethernet. The
default is 10 Gbps. All ports are configured to the same speed; there is no
mixed-rate-mode capability. You can use either the SFP-1GE-SX or the SFP-1GE-LX
transceiver for 1 Gbps. Changing the port speed causes the PIC to reboot.
To configure all ports on the P1-PTX-24-10GE-SFPP to operate at 1 Gbps, use the speed
1G statement at the [edit chassis fpc fpc-number pic pic-number] hierarchy level. To
return all ports to the 10-Gbps speed, use the delete chassis fpc fpc-number pic
pic-number speed 1G command.
[See speed (24-port and 12-port 10 Gigabit Ethernet PIC) and 10-Gigabit Ethernet PIC
with SFP+ (PTX Series).]
214
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.
[See Understanding YANG on Devices Running Junos OS.]
MPLS
•
Egress peer engineering of service labels (BGP, MPLS) and egress peer protection
for BGP-LU (PTX Series)—Beginning with Junos OS Release 14.2R4, you can enable
traffic engineering of service traffic, such as MPLS LSP traffic between autonomous
systems (ASs), using BGP-labeled unicast for optimum utilization of the advertised
egress routes. You can specify one or more backup devices for the primary egress AS
boundary router. Junos OS installs the backup path in addition to the primary path in
the MPLS forwarding table, which enables MPLS fast reroute (FRR) when the primary
link fails.
[See Egress Peer Protection for Labeled BGP Overview.]
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.]
Network Management and Monitoring
•
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.
[See show snmp stats-response-time and show snmp statistics.]
Copyright © 2016, Juniper Networks, Inc.
215
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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.
[See commit (system) and delta-export.]
Routing Policy and Firewall Filters
•
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.
[See Filter-Based Forwarding Overview.]
•
216
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 walks 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.
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
Routing Protocols
•
Remote LFA support for LDP in IS-IS (PTX 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, 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.]
Software Installation and Upgrade
•
Unified ISSU support (PTX3000)—Beginning with Junos OS Release 14.2R3, unified
in-service software upgrade (ISSU) is supported on the PTX3000 router. Unified 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 ISSU is not supported
on the P1-PTX-24-10G-W-SFPP PIC.
[See Unified ISSU System Requirements.]
User Interface and Configuration
•
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
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Copyright © 2016, Juniper Networks, Inc.
217
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Changes in Behavior and Syntax
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.2R6 for the PTX
Series.
•
Class of Service (CoS) on page 218
•
Junos OS XML API and Scripting on page 218
•
Network Management and Monitoring on page 218
•
Routing Protocols on page 218
•
User Interface and Configuration on page 219
Class of Service (CoS)
•
Change to interpolated WRED drop probability (PTX Series)—In Junos OS Releases
13.2R4, 13.3R2, and 14.1 and later releases, 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.
Junos OS XML API and Scripting
•
Escaping of special XML characters required for request_login (PTX
Series)—Beginning with Junos OS Release 14.2R4, you must escape any special
characters in the username and password elements of a request_login XML RPC request.
The following five symbols are considered special characters: greater than (>), less
than (<), single quote (’), double quote (“), and ampersand (&). Both entity references
and character references are acceptable escape sequence formats. For example,
&amp; and &#38; are valid representations of an ampersand. Previously no escaping
of these characters was required.
Network Management and Monitoring
•
New system log message indicating the difference in the Packet Forwarding Engine
counter value (PTX Series)—In Junos OS Release 14.2R2 and later, if the counter value
of a Packet Forwarding Engine is reported lesser than its previous value, then the
residual counter value is added to the newly reported value only for that specific counter.
In that case, the CLI shows the MIB2D_COUNTER_DECREASING system log message
for that specific counter.
[See MIB2D_COUNTER_DECREASING.]
Routing Protocols
•
218
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.
The default behavior has changed such that the behavior of the mvpn-iana-rt-import
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
statement has become the default. The mvpn-iana-rt-import statement is deprecated
and we recommend that you remove it from configurations.
•
OSPFv3-TTL propagation policy for TE-Shortcuts and FA-LSPs in line with other
modules in the system (PTX Series)—Starting in Junos OS Release 14.2, the
OSPFv3-TTL propagation policy is dictated by the MPLS-TTL propagation policy which,
by default, allows propagation of TTL.
This change makes the behavior of OSPFv3 in line with the default behavior of rest of
the system, allowing you to disable TTL propagation for the above mentioned LSPs,
and for traffic-engineering-shortcuts (TE-Shortcuts) and forwarding adjacency LSPs
(FA-LSPs) using OSPFv3 as the IGP, by configuring the no-propagate-ttl statement at
the [edit protocols mpls] hierarchy level.
User Interface and Configuration
•
Configuring regular expressions (PTX Series)—In all supported Junos OS releases,
you can no longer configure regular expressions 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
•
New and Changed Features on page 210
•
Known Behavior on page 219
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Known Behavior
This section contains the known behavior, system maximums, and limitations in hardware
and software in Junos OS Release 14.2R6 for the PTX Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
General Routing on page 220
Copyright © 2016, Juniper Networks, Inc.
219
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
General Routing
Related
Documentation
•
The PIC P2-100GE-CFP2 supports 100GBASE-LR4 and 100GBASE-SR10 transceivers
on the FPC FPC2-PTX-P1A in a PTX5000 router. The CFP2-100G-SR10-D2 transceiver
is dual-rate, but only when used in a PIC that supports OTN, such as P2-100GE-OTN.
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R6
for the PTX Series.
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
General Routing on page 220
•
Infrastructure on page 221
•
Interfaces and Chassis on page 221
•
MPLS on page 222
•
Routing Protocols on page 222
•
Software Installation and Upgrade on page 222
General Routing
•
CCG configuration change does not reprogram hardware automatically. PR896226
•
jnxOperatingDRAMSize mib is deprecated because this is 32-bit mib in bytes and new
memory size cannot be expressed using this mib. Please use jnxOperatingMemory that
gives memory size in MegaBytes. PR949656
•
Without explicit EXP rewrite configuration, the EXP bits of the top label is rewritten on
the egress MPLS frame following the default EXP rewrite profile. There is no workaround.
PR976481
•
220
IS-IS adjacencies starts to flap at higher scale(2k+) with default timers. Issue is not
seen at lower scale(<100 adjacencies). As a workaround, please increase the default
timers. PR1036914
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
On FPC3, strict priority mode scheduling may not be accurate with large packet sizes.
PR1099387
•
If a static route points to a set of interfaces effectively resulting in static route pointing
to a unilist nexthop, it is possible that the selector weights may not be initialized correctly
resulting in traffic drop. You can mitigate this issue by deactivating and then activating
the static route configuration. PR1120370
Infrastructure
•
The 'show system memory' command does not work on 64 bit systems. The
implementation requires the use of loadable kernel module to gather data. This module
has known issues and has been the root cause of numerous kernel panics. In addition
the pmap utility which provides the data for the cli has known, rare, crashes on 32 bit
kernels. In the case when the pmap utility crashes no information will be reported by
the CLI. PR883953
Interfaces and Chassis
•
During an RE switchover in which OAM-AH (LFM) is configured, the peer router may
see syslog entries which indicate an LFM session new state of up. These logs are
harmless however rightfully cause concern that the LFM session had dropped, which
is not the case. PR775616
•
Kernel crash may happen when a router running a junos install with the fix to PR 937774
is rebooted. This problem problem will not be observed during the upgrade to this junos
install. It occurs late enough in the shutdown procedure that it shouldn't interfere with
normal operation. PR956691
Copyright © 2016, Juniper Networks, Inc.
221
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MPLS
•
In RSVP-based P2MP scenario, if a sub-LSP switchover to bypass LSP due to PIC
offline, then when a new sub-LSP is established via setup-protection, then the deletion
of the old sub-LSP might result in deletion of both the sub-LSPs. PR1132050
Routing Protocols
•
When we have two paths for the same route, the route gets pointed to Unilist NH which
inturn gets pointed to two separate Unicast NHs. The route is determined by OSPF
and we have BFD enabled on one of the paths which runs through an l2circuit path.
When the link on the l2circuit gets cut, the link flap is informed by BFD as well as through
OSPF LSAs. Ideally the BFD should inform the link down event before the OSPF LSA.
But at the current situation, the OSPF LSAs update the current event a second before
BFD. Due to this reason, we do get the route to be pointing to a new UNILIST NH with
the weights swapped. But the Unicast NH for which the L3 link is down, gets added to
the Unilist NH, the BFD assumes the link to be up, and hence updates the weights
inappropriately and hence we do see traffic loss Once the BFD link down event is
processed at OSPF protocol level, now the route points to only UNICAST NH and hence
we do see traffic flowing through the currently active link The traffic outage would be
hardly for less than a second during FRR. Also, this can be avoided if the BFD keepalive
intervals are maintained around 50 ms with multiplier as 3 as opposed to 100ms with
a multiplier of 3 PR1119253
Software Installation and Upgrade
Related
Documentation
•
Due to buffer size issue for FPC-SFF-PTX-P1-A (ptx3000) and FPC2-PTX-P1A
(ptx5000) will be hitting "ISSU RECONNECT TIMEOUT" or "READY Message Without
Reconnect" during ISSU( it will be hit if this fix not available in the from build). PR1155936
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Resolved Issues
This section lists the issues fixed in the Junos OS main release and the maintenance
releases. The identifier following the description is the tracking number in the Juniper
Networks Problem Report (PR) tracking system.
222
•
Resolved Issues: 14.2R6 on page 223
•
Resolved Issues: 14.2R5 on page 224
•
Resolved Issues: 14.2R4 on page 226
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Resolved Issues: 14.2R3 on page 227
•
Resolved Issues: 14.2R2 on page 229
Resolved Issues: 14.2R6
•
Class of Service (CoS) on page 223
•
General Routing on page 223
•
High Availability (HA) and Resiliency on page 224
•
Routing Protocols on page 224
•
VPNs on page 224
Class of Service (CoS)
•
This PR does optimization in AE SNMP handling. If all the links in an AE bundle go down,
then any COS SNMP query for this AE IFD/IFL will return cached values PR1140440
General Routing
•
It is reported that on PTX platforms, when the firewall filter is configured on the
loopback interface of the device, due to bad error handling or NULL pointer, all the FPC
on device may continuously crash and unstable. Because the issue is not reproducible,
the trigger of the issue is not clear. PR996749
•
When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP
routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP
routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the
rpd process might crash. PR1063796
•
When hold-time Up is configured on IFDs of PTX, SyncE line clocks can fail by restarting
the associated FPCs. In a paticular test scenario with relatively large hold-time Up
60,000 ms, SyncE line clock can fail by restarting the associated FPC, and it is never
recovered until the IFD is dis/enabled. Both 10GbE and 100GbE interfaces indicate the
same clock fail issue. PR1130084
Copyright © 2016, Juniper Networks, Inc.
223
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
High Availability (HA) and Resiliency
•
With NSR enabled on multiple RE system, when dynamic GRE tunnel is configured,
performing RE switchover might causing rpd crash repeatedly on backup RE. PR1130203
Routing Protocols
•
In multicast environment, when the RP is FHR (first hop router) and it has MSDP peers,
when the rpf interface on RP changed to MSDP facing interface, due to the multicast
traffic is still on the old rpf interface, a multicast discard route will be installed and
traffic loss will be seen. PR1130238
VPNs
•
For Layer 2 circuit, PTX3000 uses different VCCV (Virtual Circuit Connectivity
Verification) BFD control packet format from that of MX and the other PTX platforms.
PTX3000 negotiates Router-alert control channel type, and uses PW Associated
Channel Header of Channel Type : 0x0021. However, MX and the other PTX platforms
use the Channel Type is 0x0007 without IP/UDP headers. JUNOS takes the
Channel-type 0x0007 as default. MX and the other PTX platforms work as expected.
This is PTX3000 specific issue. PR1116356
Resolved Issues: 14.2R5
•
General Routing on page 224
•
Interfaces and Chassis on page 226
•
MPLS on page 226
•
Network Management and Monitoring on page 226
•
Platform and Infrastructure on page 226
•
Routing Protocols on page 226
•
Software Installation and Upgrade on page 226
General Routing
•
When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP
routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP
routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the
rpd process might crash. PR1063796
•
When a switchover is done from one Routing Engine to the other, in graceful-switchover
redundancy mode, there is a brief period early in the transition of the SIB to online state,
during which unsoliciited (not corresponding to an attempt by the CPU to access the
SIB via PCIe) errors are received at the downstream PCIe port on the CB to the SIB.
The fix is to mute the generation of such errors during this brief period of the switchover.
PR1068237
•
224
On PTX5000 platform with FPC2 equipped, if 48x10G/12x40G PIC or 4X100G PIC is
inserted into the FPC, continuous "pmbus_get_devaccess: fpc PMBUS dev table not
initialized" error logs might be seen on the device due to memory corruption. These
errors are mostly seen when making the OTN related configuration change (e.g. set
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
up OTN rates). But it is not the only trigger. For example, physical interface (IFD)
disable/enable may result in the issue too. The messages might disappear for some
time by restarting the FPC, however, the corruption will still exist. PR1077985
•
The FPC on PTX Series router might crash and reboot when the Packet Forwarding
Engine is handling a fatal error, when the error happened, "TQCHIP0: Fatal error
pqt_min_free_cnt is zero" log message will be seen. PR1084259
•
On PTX Series platform with external clock synchronization interface configured, when
both BITS external clocks are disconnected at the same time, the 100GbE-LR4 FINISAR
interface might flap. This link flap issue is narrowed down to the operation of data-path
FIFO within CFP. When both the BITS clocks are disconnected, the reference clock
jumps to "free-running" mode. This transition leads to a phase shift in reference clock.
Due to this phase shift, the data rates into and out of the FIFO will temporarily not
match, leading to a FIFO over-run or under-run condition. This over-run or under-run
condition forces a FIFO reset, and the output signal is distorted. So the far-end interface
detects 'local-fault', then return 'remote-fault' back to the near-end, hence a link flap.
After change for this PR: - User need to manually config FPC recovered clock port for
each clock put into "chassis synchronization source". - Only one clock of each FPC can
be put into "chassis synchronization source". PR1091228
•
On PTX platform, if there are scaling configurations (for example,5000 routes and
each of them with 64 ECMP paths configured) on a single interface and L2 rewrite
profile is applied for the interface, the FPC may crash when deactivating and then
activating the CoS configuration of the interface. PR1096958
•
Entropy Label Capability is enabled by-default on all Juniper Networks PTX Series
platforms. On PTX Series transit LSRs that carry LSPs with Entropy Label Capability,
packet loss can be observed due to data errors when one or more labeled route entries
are not properly removed from the hash table (ie. following LSP optimization or MBB
event) because the 'stale' entries are pointing to corrupted route memory. As a result,
when the MPLS label that is associated with the 'stale' entry is re-used, data errors
are seen for packets using the corresponding label. PR1100637
•
FFP is a generic process that shall be called during commit process, and FFP calls the
PDB initialization as part of its process. On the PDB-unsupported platforms , when
committing configuration, some error messages will be seen. PR1103035
•
On PTX Series platform, when yanking out FPC or SIB ungracefully (for example, pulling
the line card out of the chassis unintentionally when the line card is carrying the traffic),
there might be small probability that it can impact any of the FPCs with Grant Scheduler
(GS) and Request Table (RT) fatal interrupt occurred. PR1105079
Copyright © 2016, Juniper Networks, Inc.
225
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Interfaces and Chassis
•
On PTX platform, if the configurations that have per-unit-scheduler configured on the
interface, but without proper class-of-service configuration for the same interface, due
to lack of commit check, the device control daemon (dcd) may fail to return "commit
error" and pass the configuration. Following is an example, [email protected]# set interfaces
et-0/0/1 per-unit-scheduler vlan-tagging unit 0 <<<<< The configuration for interface
et-0/0/1 [email protected]# commit check error: per-unit-scheduler is configured but
class-of-service is blank <<<<< This is correct behavior error: configuration check-out
failed <<<<< .. [email protected]# set class-of-service forwarding-classes queue 7 q7 <<<<<
[email protected]# commit check configuration check succeeds <<<<< This is wrong behavior
because et-0/0/1 does not have class-of-service configuration * If reboot this router
after committing, the administrator cannot access without console because the router
cannot read this configuration. When deleting the above configuration after rebooting,
telnet and so on could be used. PR1097829
MPLS
•
In the output of the CLI command "traceroute mpls ldp", the addresses of the interfaces
on transit PTX Series routers might be shown as "127.0.0.1". PR1081274
•
When an LSP is link-protected and has no-local-reversion configured, if the primary
link (link1) is down and LSP on bypass (link2), then another link (link3) is brought up,
before the LSP switch to link3. If link1 is enabled and link3 is disabled, the LSP will stuck
in bypass LSP forever. This is a timing issue. PR1091774
Network Management and Monitoring
•
Due to inappropriate cleanup in async library, disable multiple interfaces while SNMP
is polling interface oids might cause mid2d process crashing. PR1097165
Platform and Infrastructure
•
The MIB counter or "show pfe statistics traffic" shows junk PPS and invalid total traffic
output counter. PR1084515
Routing Protocols
•
In Junos OS release 14.1R1 and later, the rpd process might crash while executing CLI
command "show isis backup spf results". PR1037114
Software Installation and Upgrade
•
In certain conditions, when /var is not mounted from a persistent filesystem, executing
a Junos OS upgrade will have unexpected results. This is caused by an inexact check
of whether we're running from an Emergency VAR. PR1112334
Resolved Issues: 14.2R4
•
226
General Routing on page 227
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
General Routing
•
CLI commands are enabled for PTX5000, which were supported earlier on MX Series
only. PR1038995
Resolved Issues: 14.2R3
•
General Routing
•
Interfaces and Chassis
•
MPLS
•
Platform and Infrastructure
•
Routing Protocols
General Routing
•
Prior to this fix "show interface diagnostics optics" command shows output for all four
lanes for 10G ports of 48x10GE 12x40GE QSFP+ PIC. Normal behavior would be to
display output for only the lane that the port belongs to. PR959514
•
On PTX5000, the packet drop is observed along with the parity error read from l3bnd_ht
entry corresponding to certain addresses. With this SRAM parity error, ASIC will
unconditionally drop the packet even if PTX Series does not use l3bnd_ht during lookup.
The parity check for l3bnd_ht lookup for PTX5000 will be disabled to avoid the SRAM
parity error and packet drop as a workaround. We also add new log message to report
the counter value change for slu.hw_err trap count - TL[<num>]: SLU hw error count
<xxx> (prev count <yyy>). PR1012513
•
A reboot might be required when chassis is powered up the first time. PR1034662
•
Using jnxoptIfOTNPMFECIntervalTable and jnxOpticsPMIntervalTable it is not possible
to walk these tables from the middle before this fix. PR1039030
•
When there is link/node protection/ECMP for RSVP/LDP transit or egress LSPs with
huge scaling and continuous flapping of LSPs like auto-bandwidth case, traffic might
get black-holed upon LSP re-optimizations. The issue would get triggered if the same
unilist list-id (unilist list-id is a unique id for unilist nexthop) is allocated for two different
unilist forwarding topologies. This situation arises when the unilist list-id wraps around
after max value of 65535. After the wraparound, if there is a long living list-id (which
can be due to some node/link protected LSP that has not been re-optimized for a long
time), the Packet Forwarding Engine assigns the same list-id during allocation (upon
other LSP re-optimizations), and this will trigger the issue as the new unilist will be
directed to incorrect interface. PR1043747
•
On PTX Series platform running Junos OS Release 12.1 and later, for interface connected
via optical system such as DWDM, when the interface is administratively disabled,
there might be a delay (300-400msec) for the system to detect the event and during
which time, traffic blackhole might be seen. Note if you disable the interface by breaking
the Rx or Tx link, the issue will not happen. PR1043762
•
On PTX Series platform with one of the following protocols configured, flapping the
protocols will trigger the Composite Next-hop change operation. In rare condition,
Copyright © 2016, Juniper Networks, Inc.
227
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
since it is not properly programmed, the FPC might crash. This is a day-1 issue. - LDP MPLS - Point-to-Multipoint LSP - RSVP - Static LSPs PR1045794
•
For PTX Series router, the unilist next-hop member will have a 'replaced' status on the
Packet Forwarding Engine after interface flapping with ARP timeout. While the problem
is happening, the routing table will display an all right next-hop status but cannot
forward traffic since the forwarding next-hop in the Packet Forwarding Engine is in
'replaced' status and no longer active. PR1046778
•
On PTX Series platform, non-revertive feature for clock synchronous sources does not
work correctly. After deleting the primary clock and then adding it back, it will fallback
to the primary clock but not stay in secondary. PR1052549
•
When the port on 24x 10GE(LWO) SFP+ (which never went link up since the PIC is
onlined) is configured as CLI loopback, the ports will receive framing error during until
the interface gets physically linked up. (that is, with real fiber instead of CLI loop). There
would be no problem in normal use. This is only seen in self-loopback testing with CLI
loopback. PR1057364
•
In LDP tunneling over single hop RSVP-based LSP environment, after enabling
"chained-composite-next-hop", the router might fail to create the chained composite
next hops if the label value of VPN is equal to the label value of LDP. PR1058146
•
On PTX Series routers, the interrupt-driven basis link-down detection (an
interrupt-driven link-down notification is generated to trigger locally attached systems
to declare the interface down within a few milliseconds of failure) might fail after
performing unified in-service software upgrade (ISSU). The interrupt might be prevented
after performing unified ISSU due to disable the interrupt registers before unified ISSU
but never restored afterwards. PR1059098
•
On PTX Series routers, the interrupt-driven link-down detection might stop working.
When the line card is receiving a multiple back-to-back fault in a very short duration
(no matter from remote or local), it might fail to detect all the received interrupts, and
this failure might cause delay of the link-down detection (for example, it might take
PTX Series ~300ms to make interface down). PR1060279
Interfaces and Chassis
•
Configuring ODU FRR under otn-options for 2x100G DWDM PIC is an unsupported
command on PTX Series router. Adding such configuration could result in an FPC crash
and restart. PR1038551.
MPLS
•
On P2MP MPLS LSP transit router with NSR enabled, when RSVP refresh reduction
feature is enabled and LSP link protection is configured on all interfaces, slight P2MP
traffic loss might be seen after the graceful Routing Engine switchover (GRES) is done.
PR1023393
•
228
This is a regression issue on all Junos OS releases related to a timing factor. When LDP
session flaps, over which entropy label TLV or any unknown TLV is received, the LDP
speaker might not send label withdraw for some prefixes to some neighbors. As a
result, these neighbors will still use stale labels for the affected prefixes. PR1062727
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Platform and Infrastructure
•
In some rare conditions, setting up configuration access privilege using the
"allow-configuration-regexps" or "deny-configuration-regexps” statements will crash
the management daemon (mgd), which serves a central role in the user interface
component of Junos OS. PR1029384
Routing Protocols
•
After adding Shared Risk Link Group (SRLG) configuration on an interface, the interface
would be deleted from the TED database. If the interface is traversed by LSP optimal
path, in some cases, the re-optimization that occurs selects a sub-optimal path.
PR1035359
•
In MPLS TE scenario, if IS-IS shortcuts for family inet6 are enabled, the LSP flapping
might cause memory leak, which could result in traffic blackhole or FPC crash.
PR1049675
•
When running Simple Network Management Protocol (SNMP) polling to specific IS-IS
Management Information Base (MIB) with invalid variable, it will cause the routing
protocol process (rpd) to crash. PR1060485
Resolved Issues: 14.2R2
•
General Routing
•
MPLS
•
Routing Protocols
•
User Interface and Configuration
General Routing
•
LACP on AE interfaces currently does not support unified ISSU on PTX Series platform,
so a warning message is present before performing unified ISSU with LACP configured.
Then the user can discontinue the ISSU process. PR1018233
•
On PTX Series, route installation might fail. PR1029548
•
On PTX Series platform with equal-cost multipath (ECMP) route, bouncing the route
next-hop interface hosted PIC, the Packet Forwarding Engine might get the route
next-hop change message before the interface up message when the PIC is coming
up, which results in the next-hop not installed in Packet Forwarding Engine leading to
traffic black-holing. PR1035893
•
PCS statistics counter is now displayed for PTX Series 100GE interfaces in this
command: cli > monitor interface <intf> PR1030819
Copyright © 2016, Juniper Networks, Inc.
229
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
MPLS
•
In MPLS traffic engineering with link or node protection enabled, after adding Shared
Risk Link Group (SRLG) configuration, the bypass LSP might ignore the constraint and
use an unexpected path. PR1034636
Routing Protocols
•
With any single hop BFD session and MPLS OAM BFD session configured over same
interface, when the interface is disabled and enabled back immediately (e.g. a delay
of 10 sec between the two commit check in), the single hop BFD session might get
stuck into Init-Init state due to Down packet is received from other end for MPLS BFD
session on the same interface might get demultiplexed to single hop BFD session
wrongly. PR1039149
User Interface and Configuration
Related
Documentation
•
Commit Error happens with load patch or load replace, while applying commit difference
on backup Routing Engine as part of fast commit process. Error looks like [email protected]# commit check re0: configuration check succeeds re1:
/var/tmp/juniper.db-2233-patch.sync:9:(0) syntax error error: remote
load-configuration failed on re1. PR1029474
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Documentation Updates
There are no outstanding issues with the published documentation for Junos OS Release
14.2R6 for the PTX Series.
Related
Documentation
230
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Migration, Upgrade, and Downgrade Instructions on page 231
•
Product Compatibility on page 234
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
Migration, Upgrade, and Downgrade Instructions
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 231
•
Upgrading a Router with Redundant Routing Engines on page 231
•
Basic Procedure for Upgrading to Release 14.2 on page 231
Upgrading Using Unified ISSU
CAUTION: This release introduces some behavior changes to the unified
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 Release 14.2.
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:
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.
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.
Copyright © 2016, Juniper Networks, Inc.
231
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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:
[email protected]> 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.
232
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
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.
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.
Customers in the United States and Canada, use the following command:
[email protected]> request system software add validate reboot
source/jinstall-14.2R5.9-domestic-signed.tgz
Copyright © 2016, Juniper Networks, Inc.
233
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
All other customers, use the following command:
[email protected]> request system software add validate reboot
source/jinstall-14.2R5.9-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)
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.
Related
Documentation
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Product Compatibility on page 234
Product Compatibility
•
234
Hardware Compatibility on page 235
Copyright © 2016, Juniper Networks, Inc.
Product Compatibility
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 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:
http://pathfinder.juniper.net/feature-explorer/
Related
Documentation
•
New and Changed Features on page 210
•
Changes in Behavior and Syntax on page 218
•
Known Behavior on page 219
•
Known Issues on page 220
•
Documentation Updates on page 230
•
Migration, Upgrade, and Downgrade Instructions on page 231
Copyright © 2016, Juniper Networks, Inc.
235
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 of the Juniper Networks TechLibrary 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
http://www.juniper.net/techpubs/feedback/.
•
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.
•
236
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 .
Copyright © 2016, Juniper Networks, Inc.
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:
[email protected]> 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/.
Copyright © 2016, Juniper Networks, Inc.
237
Release Notes: Junos OS Release 14.2R6 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Revision History
29 April 2016—Revision 4, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
26 April 2016—Revision 3, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
20 April 2016—Revision 2, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
12 April 2016—Revision 1, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
16 March 2016—Revision 5, Junos OS Release 14.2R5– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
15 March 2016—Revision 4, Junos OS Release 14.2R5– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
6 January 2016—Revision 3, Junos OS Release 14.2R5– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
7 December 2015—Revision 2, Junos OS Release 14.2R5– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
30 November 2015—Revision 1, Junos OS Release 14.2R5– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
9 November 2015—Revision 6, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
8 October 2015—Revision 5, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
21 September 2015—Revision 4, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
15 September 2015—Revision 3, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
8 September 2015—Revision 2, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
31 August 2015—Revision 1, Junos OS Release 14.2R4– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
2 July 2015—Revision 6, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
9 June 2015—Revision 5, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
238
Copyright © 2016, Juniper Networks, Inc.
Requesting Technical Support
29 May 2015—Revision 4, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
28 May 2015—Revision 3, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
21 May 2015—Revision 2, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
15 May 2015—Revision 1, Junos OS Release 14.2R3– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
7 April 2015—Revision 6, Junos OS Release 14.2R2– EX Series, M Series, MX Series, PTX
Series, and T Series.
27 March 2015—Revision 5, Junos OS Release 14.2R2– EX Series, M Series, MX Series,
PTX Series, and T Series.
12 March 2015—Revision 4, Junos OS Release 14.2R2– EX Series, M Series, MX Series,
PTX Series, and T Series.
12 February 2015—Revision 3, Junos OS Release 14.2R2– EX Series, M Series, MX Series,
PTX Series, and T Series.
5 February 2015—Revision 2, Junos OS Release 14.2R2– EX Series, M Series, MX Series,
PTX Series, and T Series.
29 January 2015—Revision 1, Junos OS Release 14.2R2– EX Series, M Series, MX Series,
PTX Series, and T Series.
19 November 2014—Revision 3, Junos OS Release 14.2R1– EX Series, M Series, MX Series,
PTX Series, and T Series.
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 © 2016, 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.
Copyright © 2016, Juniper Networks, Inc.
239
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement