®
Release Notes: Junos OS Release 14.2R7
for the EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion
20 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Copyright © 2016, Juniper Networks, Inc.
1
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Open vSwitch Database (OVSDB) Management Protocol . . . . . . . . . . . 18
OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Resolved Issues: Release 14.2R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Resolved Issues: Release 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Resolved Issues: Release 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Resolved Issues: Release 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Resolved Issues: Release 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Resolved Issues: Release 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 28
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 28
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Junos OS Release Notes for Junos Fusion Provider Edge . . . . . . . . . . . . . . . . . . . . 31
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Multicast Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Satellite Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Resolved Issues: Release 14.2R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Resolved Issues: Release 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Resolved Issues: Release 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Resolved Issues: Release 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Resolved Issues: Release 1.0R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Resolved Issues: Release 1.0R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Resolved Issues: Release 1.0R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . . 49
Basic Procedure for Upgrading an Aggregation Device . . . . . . . . . . . . . . 50
Upgrading an Aggregation Device with Redundant Routing Engines . . . 52
Preparing the Switch for Satellite Device Conversion . . . . . . . . . . . . . . . 53
Autoconverting a Switch into a Satellite Device . . . . . . . . . . . . . . . . . . . . 54
Manually Converting a Switch into a Satellite Device . . . . . . . . . . . . . . . 56
Configuring a Switch into a Satellite Device Before Connecting It to a
Junos Fusion Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Configuring Satellite Device Upgrade Groups . . . . . . . . . . . . . . . . . . . . . 59
Converting a Satellite Device to a Standalone Device . . . . . . . . . . . . . . . 60
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 62
Downgrading from Release 14.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D
Universal Edge Routers, and T Series Core Routers . . . . . . . . . . . . . . . . . . . . 65
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authentication, Authorization and Accounting (AAA) (RADIUS) . . . . . . 67
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Junos Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Layer 2 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Operation, Administration, and Maintenance (OAM) . . . . . . . . . . . . . . . 87
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Copyright © 2016, Juniper Networks, Inc.
3
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 108
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Subscriber Management and Services . . . . . . . . . . . . . . . . . . . . . . . . . . 120
System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
VPNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
High Availability (HA) and Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Layer 2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Layer 2 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Resolved Issues: 14.2R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Resolved Issues: 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Resolved Issues: 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Resolved Issues: 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Resolved Issues: 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Resolved Issues: 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Adaptive Services Interfaces Feature Guide for Routing Devices . . . . . 242
Broadband Subscriber VLANs and Interfaces Feature Guide . . . . . . . . 243
High Availability Feature Guide for Routing Devices . . . . . . . . . . . . . . . 244
4
Copyright © 2016, Juniper Networks, Inc.
Monitoring, Sampling, and Collection Services Interfaces Feature Guide
for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
MPLS Applications Feature Guide for Routing Devices . . . . . . . . . . . . . 245
Overview for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide for
Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Services Interfaces Configuration Guide . . . . . . . . . . . . . . . . . . . . . . . . . 246
Standards Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Subscriber Access Protocols Feature Guide . . . . . . . . . . . . . . . . . . . . . . 246
Subscriber Management Access Network Guide . . . . . . . . . . . . . . . . . . 247
Subscriber Management Provisioning Guide . . . . . . . . . . . . . . . . . . . . . 248
Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Tunnel and Encryption Services Interfaces Feature Guide for Routing
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
User Access and Authorization Feature Guide for Routing Devices . . . 249
VPNs Library for Routing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . 250
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . 250
Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . 253
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 253
Upgrading Juniper Network Routers Running Draft-Rosen Multicast
VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . 255
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled
for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Downgrading from Release 14.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Changes Planned for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Junos OS Release Notes for PTX Series Packet Transport Routers . . . . . . . . . . . 261
New and Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 266
Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Changes in Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Copyright © 2016, Juniper Networks, Inc.
5
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Junos OS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Network Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 269
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Known Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Resolved Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Resolved Issues: 14.2R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Resolved Issues: 14.2R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Resolved Issues: 14.2R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Resolved Issues: 14.2R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Resolved Issues: 14.2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Resolved Issues: 14.2R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Migration, Upgrade, and Downgrade Instructions . . . . . . . . . . . . . . . . . . . . . 283
Upgrading Using Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 283
Basic Procedure for Upgrading to Release 14.2 . . . . . . . . . . . . . . . . . . . 284
Product Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Hardware Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Third-Party Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
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.2R7 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.2R7 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 15
•
Known Behavior on page 17
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R7 for the EX Series.
NOTE: The following EX Series platforms are supported in Junos OS Release
14.2R7: 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.2R7 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.2R7 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 29.]
•
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.2R7 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.]
•
Support for firewall filter flexible match conditions (EX9200)—Starting with Junos
OS Release 14.2R7, EX9200 switches support flexible match conditions under family
ethernet-switching for firewall filters. Standard firewall filter match conditions vary
based on the protocol family of the traffic being matched. The fields available for
matching within each protocol family are fixed or predefined. This means that filters
can match on patterns within those predefined fields only. Using flexible match
conditions, you can construct flexible match filter terms that start the match at Layer
2, Layer 3, Layer 4, or payload locations. You can enable further pattern matches at
user-defined custom locations within a packet by specifying additional offset criteria.
Flexible match filter terms are applied to interfaces as either input or output filters just
as any other firewall filter terms. Flexible match filter terms can also be created as
templates at the [edit firewall] hierarchy level. These templates can then be referenced
within a flexible match term.
[See Firewall Filters Match Conditions.]
Copyright © 2016, Juniper Networks, Inc.
13
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
14
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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 15
•
Known Behavior on page 17
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
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.2R7 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
•
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.
15
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
•
Configuration statement to correct mismatches between MAC and ARP entries in
MC-LAGs (EX9200)—Starting with Junos OS Release 13.2R4 but first documented in
Release 14.2R6, the arp-l2-validate configuration statement is available as a workaround
when network issues or conditions result in MAC and ARP entries going out of sync in
an MC-LAG scenario. Configure the arp-l2-validate statement at the [edit interfaces
irb] hierarchy level to recognize and correct mismatches between MAC and ARP entries
related to the next-hop interface. You can remove the arp-l2-validate configuration
when the network issues or conditions are resolved.
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
16
•
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 17
•
Known Issues on page 20
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
Known Behavior
This section lists known behavior, system maximums, and limitations in hardware and
software in Junos OS Release 14.2R7 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.
•
Authentication and Access Control
•
Infrastructure
•
Interfaces and Chassis
•
Network Management and Monitoring
•
Open vSwitch Database (OVSDB) Management Protocol
•
OpenFlow
•
Software Installation and Upgrade
•
VXLAN
Authentication and 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 has more 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
Copyright © 2016, Juniper Networks, Inc.
17
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Infrastructure
•
On EX9200 switches, the value for the udpOutDatagrams object displayed in the
output of the show snmp mib walk decimal udpOutDatagrams command is different
from the value for the same object displayed in the output of the show system statistics
udp member 0 command. The value for datagrams dropped due to no socket field is
incorrectly used as the value for udpOutDatagrams in the show snmp mib walk decimal
udpOutDatagrams output. As a workaround, use the show system statistics udp member
0 command. PR1104831
Interfaces and Chassis
•
On EX9200 switches, BFD on IRB interfaces flaps if BFD is configured for subsecond
timers. PR844951
•
On EX9200 switches, a transient loop might be seen when interfaces are brought up
on an EVPN PE device or when a PE device having one of the ESIs comes up after
reboot. PR1110285
•
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
•
On EX9200 switches, OSPF sessions between CE devices might flap when a PE device
that provides EVPN multihoming is rebooted. PR1113013
•
On EX9200 switches, with single-active EVPN, a loop might lead to an OSPF flap
between CE devices when the BGP session between the PE devices that provide EVPN
multihoming flaps. PR1113023
Network Management and Monitoring
•
On EX9200 switches, the interface index value is displayed as 0 on the sFlow collector.
PR1083226
Open vSwitch Database (OVSDB) Management Protocol
•
The amount of time that it takes for Juniper Networks devices that function as hardware
virtual tunnel endpoints (VTEPs) to learn a new MAC address after the first packet is
sent from this MAC address is a maximum of 4.5 seconds. (The amount of time depends
upon the server configuration that VMware NSX is running.) During this time, traffic
destined for this MAC address floods the VXLAN. PR962945
•
After the connections with NSX controllers are disabled on a Juniper Networks device,
interfaces that were configured to be managed by OVSDB continue to transmit traffic.
PR980577
•
18
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
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
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.
19
Release Notes: Junos OS Release 14.2R7 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 15
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R7
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.
•
Authentication and Access Control
•
Interfaces and Chassis
•
Software Installation and Upgrade
Authentication and Access Control
•
On EX9200 switches, dot1x authentication might fail, with a dot1xd core file created.
PR1204104
Interfaces and Chassis
•
20
On EX9200 FPCs with an XM chipset, an SRAM parity error might be logged during
normal operation. This behavior is expected. You can ignore the error as long as you
do not see large numbers of error messages. PR958661
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On an EX9200-6QS line card, storm control might not work for multicast traffic.
PR1191611
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
•
On EX9200 switches, if you execute a unified ISSU from Junos OS Release 14.2R6 to
Release 14.2R7, all Layer 2 and Layer 3 traffic might drop for about 7 seconds. PR1199270
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 15
•
Known Behavior on page 17
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
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.2R7 on page 21
•
Resolved Issues: Release 14.2R6 on page 22
•
Resolved Issues: Release 14.2R5 on page 22
•
Resolved Issues: Release 14.2R4 on page 23
•
Resolved Issues: Release 14.2R3 on page 24
•
Resolved Issues: Release 14.2R2 on page 26
Resolved Issues: Release 14.2R7
•
Network Management and Monitoring
•
Platform and Infrastructure
Network Management and Monitoring
•
On EX9200 switches, sFlow sampling might remain enabled after you delete an sFlow
sample-rate configuration from an interface. PR1075789
Copyright © 2016, Juniper Networks, Inc.
21
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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 continuously generate debugging-level log messages, which
consume system resources. PR1113309
Resolved Issues: Release 14.2R6
•
Authentication and Access Control
•
Interfaces and Chassis
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
•
22
On EX9200 switches, DHCP snooping and related access security features of ARP
inspection, IP source guard, neighbor discovery inspection and IPv6 source guard are
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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
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
Copyright © 2016, Juniper Networks, Inc.
23
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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
24
•
Access Control and Authentication
•
Dynamic Host Configuration Protocol
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Firewall Filters
•
Interfaces and Chassis
•
Layer 2 Features
•
OpenFlow
•
Platform and Infrastructure
•
Routing Protocols
Access Control and Authentication
•
On EX9200 switches, the output for the ptopoConnRemotePort MIB might display an
incorrect value for portIDMacAddr. PR1061073
•
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
Copyright © 2016, Juniper Networks, Inc.
25
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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
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
•
26
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:
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
1.
There is a mismatch in the link local address between the link local binding and the
dynamic binding.
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 15
•
Known Behavior on page 17
•
Known Issues on page 20
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
Documentation Updates
This section lists the errata and changes in Junos OS Release 14.2R7 for the EX Series
switches documentation.
•
Interfaces and Chassis on page 28
Copyright © 2016, Juniper Networks, Inc.
27
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Interfaces and Chassis
Related
Documentation
•
The arp-l2-validate statement at the [edit interfaces irb] hierarchy level was added to
the CLI for EX9200 switches in Junos OS Release 13.2R4 but was documented first in
Release 14.2R6.
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 15
•
Known Behavior on page 17
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Migration, Upgrade, and Downgrade Instructions on page 28
•
Product Compatibility on page 29
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 28
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.
28
Copyright © 2016, Juniper Networks, Inc.
Product Compatibility
For information on software installation and upgrade, see the Installation and Upgrade
Guide.
Related
Documentation
•
New and Changed Features on page 7
•
Changes in Behavior and Syntax on page 15
•
Known Behavior on page 17
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Product Compatibility on page 29
Product Compatibility
•
Software Compatibility on page 29
•
Hardware Compatibility on page 29
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 15
•
Known Behavior on page 17
Copyright © 2016, Juniper Networks, Inc.
29
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
30
•
Known Issues on page 20
•
Resolved Issues on page 21
•
Documentation Updates on page 27
•
Migration, Upgrade, and Downgrade Instructions on page 28
Copyright © 2016, Juniper Networks, Inc.
Junos OS Release Notes for Junos Fusion Provider Edge
Junos OS Release Notes for Junos Fusion Provider Edge
These release notes accompany Junos OS Release 14.2R7 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 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R7 for Junos Fusion Provider Edge.
•
Junos Fusion on page 31
•
Class of Service (CoS) on page 34
•
Interfaces on page 34
•
Layer 2 Protocols on page 37
•
Layer 3 Protocols on page 37
•
Multicast Protocols on page 38
•
Network Management and Monitoring on page 38
•
Software Installation and Upgrade on page 39
•
System Logging on page 40
•
VPNs on page 40
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:
Copyright © 2016, Juniper Networks, Inc.
31
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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, QFX5100-48S, QFX5100-48T, and QFX5100-96S
•
EX4300 switches—EX4300-24P, EX4300-24T, EX4300-32F, EX4300-48P,
EX4300-48T, and EX4300-48T-BF
[See Junos Fusion Overview.]
32
•
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 at 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.
New and Changed Features
•
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:
•
•
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
NOTE: The request system software rollback command does not work if
you reboot the aggregation device. Instead, issue the request system
software add command. For more information, see the “Note” on page 52
in the Basic Procedure for Upgrading an Aggregation Device section of the
Junos Fusion Provider Edge Release Notes.
•
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
Copyright © 2016, Juniper Networks, Inc.
33
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
MPC3E NG
•
MPC3E NG Q
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.
34
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
EX4300 and QFX5100 switches configured as satellite devices have a default set of
uplink interfaces.Table 1 on page 35 shows the default set of uplink interfaces that
UFD selects for failure detection.
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 (Miscellaneous ports on PIC0, PIC1, and PIC2)
0/32 through 0/35, 1/0 through 1/1, and 2/0 through 2/7
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
0/20 through 0/23
QFX5100-48S (6 QSFP+ ports)
0/48 through 0/53
QFX5100-48T (6 QSFP+ ports)
0/48 through 0/53
QFX5100-96S (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];
}
}
Copyright © 2016, Juniper Networks, Inc.
35
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
}
}
[See Overview of Uplink Failure Detection on a Junos Fusion.]
•
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.]
NOTE: EVPN cannot be configured simultaneously with MC-LAG.
•
36
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
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
[edit system commit] hierarchy level 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
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:
•
BGP
Copyright © 2016, Juniper Networks, Inc.
37
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
IS-IS
•
OSPF
[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).]
•
38
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:
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
Satellite device discovery
•
Satellite device offline
•
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
•
Satellite device converted to a standalone switch (Junos OS)
•
Standalone switch (Junos OS) converted to a satellite device
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 upgrade-group-name—Add the satellite
software and associate it with the specified upgrade group.
•
request system software delete upgrade-group upgrade-group-name—Remove the
satellite software association from the specified upgrade group.
Copyright © 2016, Juniper Networks, Inc.
39
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
request system software rollback upgrade-group upgrade-group-name—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.
[See Understanding Junos Fusion Components, Understanding Software in a Junos Fusion,
and Configuring Junos Fusion.]
System Logging
•
System log messages to indicate checksum errors on the DDR3 interface—Starting
with Junos OS Release 14.2R7, two new system log messages,
XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MINOR and
XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MAJOR, are added to indicate
memory-related problems on the interfaces to the double data rate type 3 (DDR3)
memory. These error messages indicate that an FPC has detected a checksum error,
which is causing packet drops.
The following error threshold values classify the error as a major error or a minor error:
•
Minor error— 6 to 254 errors per second
•
Major error—255 or more errors per second
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.]
•
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.
NOTE: MC-LAG cannot be configured simultaneously with EVPN.
40
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
Related
Documentation
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
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.2R7 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
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.
•
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 follows:
•
•
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, superuser, and users with class satellite all
can log in without a password.
•
Junos OS Release 14.2R6: The root user, superuser, and users with class satellite all,
permissions all, and permissions maintenance can log in without a password.
Automatic channelized interface support on QFX5100-96S satellite devices (Junos
Fusion)—Starting with Junos OS Release 14.2R7 and satellite software release 1.0R4,
port 96 and port 100 on QFX5100-96S satellite devices can be automatically
channelized as follows:
Copyright © 2016, Juniper Networks, Inc.
41
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
If the satellite device has not established a connection with the aggregation device:
•
The satellite device tries to channelize port 96 if no transceivers are inserted in ports
97 to 99.
•
The satellite device also tries to channelize port 100 if no transceivers are inserted
in ports 101 to 103.
Until the satellite device establishes a connection with the aggregation device, the
channelization mode will toggle. When this happens, the SPFE process on the
QFX5100-96S satellite device restarts and changes the channelization mode. The
autodiscovery process stops when the satellite device establishes a connection with
the aggregation device and does not restart until the satellite device reboots.
Related
Documentation
•
New and Changed Features on page 31
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
Known Behavior
This section lists known behavior, system maximums, and limitations in hardware and
software in Junos OS Release 14.2R7 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 attempt to implement MAC filtering
or MAC accounting on extended ports, the features do 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
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
42
•
New and Changed Features on page 31
•
Changes in Behavior and Syntax on page 41
•
Known Issues on page 43
•
Resolved Issues on page 44
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R7
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 3000 VLANs and 3000 IRB
interfaces in your topology, commit the configuration, and immediately issue show
and clear operational mode commands, the system might be slow to respond (more
than 10 seconds) but does recover eventually. PR1076345
•
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 Address
Resolution Protocol (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
extended period, the Flexible PIC Concentrator (FPC) might run out of memory and
stop operating. PR1114369
Satellite Software
•
On a Junos Fusion topology where the QFX5100-96S is deployed as a satellite device,
you cannot channelize the 40-Gigabit Ethernet ports. PR1052225
•
On a Junos Fusion 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, you might not be able to disable
auto-negotiation on fiber-based, Gigabit Ethernet ports in a QFX5100 switch acting
as a satellite device. PR1183112
Copyright © 2016, Juniper Networks, Inc.
43
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Related
Documentation
•
New and Changed Features on page 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Resolved Issues on page 44
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
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: Release 14.2R7 on page 44
•
Resolved Issues: Release 14.2R6 on page 45
•
Resolved Issues: Release 14.2R5 on page 46
•
Resolved Issues: Release 14.2R4 on page 46
•
Resolved Issues: Release 1.0R4 on page 46
•
Resolved Issues: Release 1.0R3 on page 48
•
Resolved Issues: Release 1.0R2 on page 48
Resolved Issues: Release 14.2R7
This section lists the issues fixed since Junos OS Release 14.2R6 for Junos Fusion Provider
Edge.
Junos Fusion
44
•
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
•
On a Junos Fusion Provider Edge topology, if you configure BFD and reboot the system,
the periodic packet management process (ppmd) might stop operating and dump
core. As a workaround, set the BFD transmit interval to 300 msec with a multiplier of
3. PR1170800
•
On a Junos Fusion Provider Edge topology, if a cascade port transitions down and up,
and the diagnostics data sent from a satellite device exceeds 25 kilobytes, the satellite
platform management process (spmd) might dump core. PR1175591
•
On a Junos Fusion Provider Edge topology, if you issue the request chassis satellite
shell-command command and the output generates more than 24 kilobytes of data,
the satellite discovery and provisioning process (SDPD) might stop operating. As a
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
workaround, issue the request chassis satellite login command and run the commands
in the resulting session. PR1188712
Resolved Issues: Release 14.2R6
This section lists the issues fixed since Junos OS Release 14.2R5 for Junos Fusion Provider
Edge.
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
•
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
•
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
•
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
•
On a 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
•
On a Junos Fusion Provider Edge topology, if you configure the aggregation device for
the first time, the 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
•
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
•
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
Copyright © 2016, Juniper Networks, Inc.
45
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Resolved Issues: Release 14.2R5
This section lists the issues fixed since Junos OS Release 14.2R4 for Junos Fusion Provider
Edge.
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
•
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
•
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
•
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
•
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
Resolved Issues: Release 14.2R4
This section lists the issues fixed since Junos OS Release 14.2R3 for Junos Fusion Provider
Edge.
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
•
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
•
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
Resolved Issues: Release 1.0R4
This section lists the issues fixed since satellite software release 1.0R3 for Junos Fusion.
46
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Satellite Software
•
On a Junos Fusion topology with QFX5100 satellite devices, if the satellite device has
a bad power supply, the output of the show chassis environment pem satellite and
show chassis alarms satellite commands might not indicate there is a problem. PR1161861
•
On a Junos Fusion topology, the CCC-DOWN state (the asynchronous notification of
link state from the remote end of a Layer 2 circuit) is not supported on satellite device
extended ports. PR1162899
•
On a Junos Fusion topology with EX4300 satellite devices, some physical interfaces
for the 10-Gigabit Ethernet ports on the uplink PIC (PIC2) are created while others are
not, and the system log might show a transceiver EPROM failure. This issue might be
resolved by removing the PIC and reinserting it, or restarting the satellite device.
PR1169555
•
On a Junos Fusion topology, when the port channelization state changes (for example,
et-0/0/1:0 to et-0/0/0) on a satellite device extended port, the system might assign
the same ECID to more than one port and the following message might be generated:
“IFRT: 'IFD hardware address configuration' (opcode 226) failed.” PR1170428
•
On a Junos Fusion topology with a QFX5100-96S satellite device, channelized interfaces
are not supported on 40-Gigabit Ethernet uplink ports. PR1179317
•
On a Junos Fusion topology with dual aggregation devices, if you issue the show snmp
mib walk command on one aggregation device, the output might not display PEM and
fan information correctly for the 124th satellite device. As a workaround, issue the
command on the second aggregation device. PR1182030
•
On a Junos Fusion topology, you might not be able to disable autonegotiation on
fiber-based Gigabit Ethernet ports in a QFX5100 switch acting as a satellite device.
PR1183112
•
On a Junos Fusion topology, if you configure CoS on an aggregation device, in some
cases the satellite devices do not get provisioned and the DPD process might stop
operating and dump core. As a workaround, disable CoS on interfaces, scheduler maps,
and traffic control profiles. PR1184828
•
On a Junos Fusion topology, if you issue the request chassis satellite shell-command
command and the output generates more than 24 kilobytes of data, the satellite
discovery and provisioning process (SDPD) might stop operating. As a workaround,
issue the request chassis satellite login command and run the commands in the resulting
session. PR1188712
•
On a Junos Fusion topology, in some cases after a satellite device PFE restart, some
of the channelized ports on a QFX5100-24Q satellite device cannot transmit or receive
traffic. PR1192218
•
On a Junos Fusion topology, if an EX4300 satellite device is connected to an aggregation
device over a copper, 40-Gigabit Ethernet uplink port, sometimes the link might
transition down and up. PR1197913
Copyright © 2016, Juniper Networks, Inc.
47
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On a Junos Fusion topology, if you issue the show interfaces command on a 40-Gigabit
Ethernet port on a QFX5100 satellite device, the output does not display the correct
bits per second if the traffic is 32 Gbps or larger. PR1197916
•
On a Junos Fusion topology, in some cases the ppman-lite or ppman process running
on the satellite device might attempt to view information in the packet beyond the
packet length, which might cause the process to stop operating. Issues with the
ppman-lite process impact LLDP functionality, while issues with the ppman process
impact LACP functionality. PR1208058
•
On a Junos Fusion topology, if you issue the request support information operational
mode command, you expect that the system will consolidate and collect information
from the /var/log directory of all the satellite devices and place it into the
/var/home/ftp/sd_logs directory of the aggregation device. However, the collected
logs (for example, sd101.tgz) do not contain relevant satellite device information from
the consolidated log files. PR1208066
•
On a Junos Fusion topology, when a QFX5100 satellite device operates continuously
for more than 140 days, or an EX4300 satellite device operates continuously for more
than 280 days, the output of the show chassis routing-engine satellite command might
indicate very high CPU utilization for the satellite device, even when the actual CPU
utilization is very low. PR1208846
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
Resolved Issues: Release 1.0R2
This section lists the issues fixed since satellite software release 1.0R2 for Junos Fusion.
Satellite Software
48
•
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
•
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
•
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
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
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
Related
Documentation
•
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
•
New and Changed Features on page 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Documentation Updates on page 49
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
Documentation Updates
This section lists the errata or changes in Junos OS Release 14.2R7 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 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Migration, Upgrade, and Downgrade Instructions on page 49
•
Product Compatibility on page 63
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 50
•
Upgrading an Aggregation Device with Redundant Routing Engines on page 52
•
Preparing the Switch for Satellite Device Conversion on page 53
Copyright © 2016, Juniper Networks, Inc.
49
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Autoconverting a Switch into a Satellite Device on page 54
•
Manually Converting a Switch into a Satellite Device on page 56
•
Configuring a Switch into a Satellite Device Before Connecting It to a Junos Fusion
Topology on page 58
•
Configuring Satellite Device Upgrade Groups on page 59
•
Converting a Satellite Device to a Standalone Device on page 60
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 62
•
Downgrading from Release 14.2 on page 63
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:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstalls
Junos OS. Configuration information from the previous software installation
is retained, but the contents of log files might be erased. Stored files on the
routing platform, such as configuration templates and shell scripts (the only
exceptions are the juniper.conf and ssh files), might be removed. To preserve
the stored files, copy them to another system before upgrading or
downgrading the routing platform. See the Junos OS Administration Library for
Routing Devices.
50
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
The download and installation process for Junos OS Release 14.2R7 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.
user@host> request system software add validate reboot
source/jinstall64-14.2R7.5-domestic-signed.tgz
•
For 32-bit software:
user@host> request system software add validate reboot
source/jinstall-14.2R7.5-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.
51
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
user@host> request system software add validate reboot
source/jinstall64-14.2R7.5-export-signed.tgz
•
For 32-bit software:
user@host> request system software add validate reboot
source/jinstall-14.2R7.5-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.2R7 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.
52
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 53 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
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
Junos OS Release 14.2R7
Junos OS Release 14.1X53-D30 or later
1.0R4
Customers with EX4300 switches, use the following command:
user@host> 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:
user@host> 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]
user@satellite-device# 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.
Copyright © 2016, Juniper Networks, Inc.
53
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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:
user@satellite-device> request virtual-chassis vc-port delete pic-slot 1 port port-number
For example, to convert all four built-in 40-Gbps QSFP+ interfaces on an EX4300-24P
switch into network ports:
user@satellite-device>request virtual-chassis vc-port delete pic-slot 1 port 0
user@satellite-device> request virtual-chassis vc-port delete pic-slot 1 port 1
user@satellite-device> request virtual-chassis vc-port delete pic-slot 1 port 2
user@satellite-device> 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.
54
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
For example, to configure interface xe-0/0/1 on the aggregation device into a cascade
port:
[edit]
user@aggregation-device# set interfaces xe-0/0/1 cascade-port
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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@satellite-device# commit synchronize
After committing the configuration, associate a satellite software image named
satellite-1.0R4.2-signed.tgz to the upgrade group named group1:
user@aggregation-device> request system software add
/var/tmp/satellite-1.0R4.2-signed.tgz upgrade-group group1
Copyright © 2016, Juniper Networks, Inc.
55
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
7. Enable automatic satellite conversion:
[edit]
user@aggregation-device# set chassis satellite-management auto-satellite-conversion
satellite slot-id
For example, to automatically convert FPC 101 into a satellite device:
[edit]
user@aggregation-device# set chassis satellite-management auto-satellite-conversion
satellite 101
8. Commit the configuration:
[edit]
user@aggregation-device# commit
If you want to commit the configuration to both Routing Engines:
[edit]
user@aggregation-device# 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]
user@aggregation-device# set interfaces xe-0/0/1 cascade-port
56
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
4. Associate an FPC slot ID with the satellite device.
Examples:
•
To configure the FPC slot ID of the satellite device that is connected to xe-0/0/1 to
101:
[edit]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@aggregation-device# 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]
user@satellite-device# commit synchronize
After committing the configuration, associate a satellite software image named
satellite-1.0R4.2-signed.tgz to the upgrade group named group1:
user@aggregation-device> request system software add
/var/tmp/satellite-1.0R4.2-signed.tgz upgrade-group group1
6. Manually configure the switch into a satellite device:
user@aggregation-device> 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:
user@aggregation-device> 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.
After the satellite software update, the switch operates as a satellite device in the
Junos Fusion topology
Copyright © 2016, Juniper Networks, Inc.
57
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 satellite software release 1.0R3 and later, a
satellite-ppc-release-signed.tgz package is included specifically for
converting Junos OS to satellite software on an EX4300 switch to address
a memory space issue. The satellite-ppc package is to be used only for
configuring a standalone EX4300 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:
user@satellite-device> request chassis device-mode satellite URL-to-satellite-software
For instance, to install the satellite software package satellite-1.0R4.2-signed.tgz
stored in the /var/tmp/ directory on the switch:
user@satellite-device> request chassis device-mode satellite
/var/tmp/satellite-1.0R4.2-signed.tgz
•
To install satellite software onto a QFX5100 switch, use the
satellite-1.0R4.2-signed.tgz satellite software package.
•
To install satellite software onto a EX4300 switch, use the
satellite-ppc-1.0R4.2-signed.tgz satellite software package.
2. The device will reboot to complete the satellite software installation.
58
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]
user@aggregation-device# 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]
user@aggregation-device# commit synchronize
To commit the configuration to a single Routing Engine:
[edit]
user@aggregation-device# 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]
user@aggregation-device# 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.
59
Release Notes: Junos OS Release 14.2R7 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]
user@aggregation-device# 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:
user@aggregation-device> request system software add upgrade-group group-name
source/satellite-1.0R4.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.
60
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]
user@aggregation-device# delete chassis satellite-management auto-satellite-conversion
satellite member-number
For example, to remove member number 101 from Junos Fusion:
[edit]
user@aggregation-device# delete chassis satellite-management auto-satellite-conversion
satellite 101
9. Commit the configuration.
To commit the configuration to both Routing Engines:
[edit]
user@aggregation-device# commit synchronize
Otherwise, commit the configuration to a single Routing Engine:
[edit]
user@aggregation-device# commit
10. Install the Junos OS software on the satellite device to convert the device to a
standalone device.
[edit]
user@aggregation-device> 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.
61
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[edit]
user@aggregation-device> 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]
user@aggregation-device> 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
62
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 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Documentation Updates on page 49
•
Product Compatibility on page 63
Product Compatibility
•
Hardware Compatibility on page 63
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 31
•
Changes in Behavior and Syntax on page 41
•
Known Behavior on page 42
•
Known Issues on page 43
•
Resolved Issues on page 44
•
Documentation Updates on page 49
Copyright © 2016, Juniper Networks, Inc.
63
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
64
Migration, Upgrade, and Downgrade Instructions on page 49
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.2R7 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 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Known Issues on page 121
•
Resolved Issues on page 139
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R7 for the M Series, MX Series, and T Series.
•
Hardware on page 66
•
Authentication, Authorization and Accounting (AAA) (RADIUS) on page 67
•
Class of Service (CoS) on page 67
•
General Routing on page 68
•
High Availability (HA) and Resiliency on page 68
•
Interfaces and Chassis on page 70
•
IPv4 on page 80
•
IPv6 on page 80
•
Junos Fusion on page 80
•
Layer 2 Features on page 80
•
Layer 2 VPN on page 82
•
Management on page 82
•
MPLS on page 82
Copyright © 2016, Juniper Networks, Inc.
65
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Multicast on page 84
•
Network Management and Monitoring on page 85
•
Operation, Administration, and Maintenance (OAM) on page 87
•
Routing Policy and Firewall Filters on page 89
•
Routing Protocols on page 91
•
Services Applications on page 93
•
Software-Defined Networking (SDN) on page 97
•
Software Installation and Upgrade on page 98
•
Subscriber Management and Services on page 98
•
System Management on page 101
•
User Interface and Configuration on page 101
•
VPNs on page 101
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.
66
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.
67
Release Notes: Junos OS Release 14.2R7 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
•
68
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.
69
Release Notes: Junos OS Release 14.2R7 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
70
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.
71
Release Notes: Junos OS Release 14.2R7 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.
•
72
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.
73
Release Notes: Junos OS Release 14.2R7 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.]
•
74
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.
75
Release Notes: Junos OS Release 14.2R7 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.
76
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.
77
Release Notes: Junos OS Release 14.2R7 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.
78
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.
•
CFP-100GBASE-ZR (MX Series)—In Junos OS Release 14.2R3 and later, the
CFP-100GBASE-ZR transceiver provides advanced dual 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
modules support the CFP-100GBASE-ZR transceiver:
•
2x100GE + 8x10GE MPC4E (MPC4E-3D-2CGE-8XGE)
•
100-Gigabit Ethernet MIC with CFP (MIC3-3D-1X100GE-CFP)
For more information about the interface modules, see the “Cables and Connectors”
section in the MX Series Interface Module Reference.
[See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications and Supported
Network Interface Standards by Transceiver for ACX, M, MX, and T Series Routers.]
Copyright © 2016, Juniper Networks, Inc.
79
Release Notes: Junos OS Release 14.2R7 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 31 for Junos Fusion.
Layer 2 Features
•
80
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.
81
Release Notes: Junos OS Release 14.2R7 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.]
82
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.
83
Release Notes: Junos OS Release 14.2R7 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
84
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.
85
Release Notes: Junos OS Release 14.2R7 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:
•
86
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.
87
Release Notes: Junos OS Release 14.2R7 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
88
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.
89
Release Notes: Junos OS Release 14.2R7 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.]
90
•
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.
•
Support for logical queue-depth in the PFE for IP options packets for a given protocol
(M Series, MX Series, and T Series)— Starting with Junos OS Release 14.2R6, you can
configure logical queue-depth in the PFE for IP options packets for a given protocol.
The queue-depth indicates the number of IP options packets which can be enqueued
in the PFE logical queue, beyond which it would start dropping the packets.
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.
91
Release Notes: Junos OS Release 14.2R7 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.
•
Flow-aware transport pseudowire for BGP L2VPN and BGP VPLS (MX Series)—
Starting with Junos OS Release 14.2R7, the flow-aware transport (FAT) label is
supported for BGP-signaled pseudowires such as L2VPN and VPLS. Configuring
flow-label-receive and flow-label-trasmit on the label edge routers (LERs) enables the
transit routers or label-switching routers (LSRs) to perform load balancing of MPLS
packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs)
without the need for deep packet inspection of the payload.
•
OSPFv3-TTL propagation policy for TE-Shortcuts and FA-LSPs in-line with other
modules in the system (MX Series)—Starting in Junos OS Release 14.2R4, the
OSPFv3-TTL propagation policy will be dictated by MPLS-TTL propagation policy
which, by default, allows propagation of TTL.
This change makes 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 IGP, by configuring the no-propagate-ttl statement at the
[edit protocols mpls] hierarchy.
92
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
Services Applications
•
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
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
Copyright © 2016, Juniper Networks, Inc.
93
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
94
•
ICMP, ping, and traceroute ALGs for MS-MICs and MS-MPCs (MX Series)—Starting
with Junos OS Release 14.2, Junos OS extension-provider packages that are preinstalled
and preconfigured on the MS-MIC and MS-MPC offer support for ping, traceroute, and
ICMP ALGs in a consistent manner that is identical to the support that the uKernel
service provides. Parity and uniformity of support is established for these ALGs between
MS-MICs/MS-MPCs and the uKernel service. Until Junos OS Release 14.1, ICMP ALGs,
ping ALGs, and traceroute ALGs were not entirely supported on MX Series routers with
MS-MICs and MS-MPCs in comparison with the uKernel service that enables Network
Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC. Support
was available for handling of ICMP error response packets that match any existing
flow in the opposite direction and NAT processing of ICMP packets with NAT processing
of ping packets.
•
Support for IP reassembly on GRE tunnel interfaces for (MX Series routers with
MPCs)—Starting with Junos OS Release 14.2, you can configure the generic routing
encapsulation (GRE) tunnel interfaces on MX Series routers with MPCs to support IP
packet reassembly. You can configure the GRE interfaces to reassemble the fragmented
packets at the endpoint of the tunnel before they can be further processed on the
network by including the reassemble-packets statement at the [edit interfaces
gr-fpc/pic/port unit logical-unit-number] hierarchy level. You can view the reassembly
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.
•
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
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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.
•
Support for H.323 NAT on MS-MPC and MS-MIC (MX Series routers)—Starting in
Junos OS Release 14.2R7, the H.323 ALG is supported in NAPT-44 rules and IPv4
stateful-firewall rules on the MX Series. H.323 is a legacy VoIP protocol.
To configure H.323 in a NAPT-44 rule, include the application-sets junos-h323-suite
statement at the [edit services nat rule rule-name term term-name from] hierarchy level.
To configure H.323 in a stateful-firewall rule, include the application-sets
junos-h323-suite statement at the [edit services stateful-firewall rule rule-name term
term-name from] hierarchy level.
To show H.323 ALG statistics, issue the show services alg statistics application-protocol
h323 command.
•
Support for AMS warm standby on MS-MPC and MS-MIC (MX Series
routers)—Starting in Junos OS Release 14.2R7, one service interface can be the backup
interface for multiple service interfaces. This feature is called AMS warm standby. To
make a service interface the backup for multiple service interfaces, you configure an
AMS interface for each service interface you want to protect. Each of these AMS
interfaces has two member interfaces—a primary member interface, which is the
service interface you want to protect, and the secondary member interface, which is
the backup service interface. You can use the same secondary member interface in
multiple AMS interfaces.
To configure a warm-standby AMS interface, include the primary mams-a/b/0
statement and the secondary mams-a/b/0 statement at the [edit interfaces amsn
redundancy-options] hierarchy level.
If you use redundancy-options in an AMS interface, you cannot use
load-balancing-options in the same AMS interface.
Copyright © 2016, Juniper Networks, Inc.
95
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
You cannot use the same member interface in both an AMS interface that includes
load-balancing-options and an AMS interface that includes redundancy-options.
To show the state of an AMS interface configured with warm standby, issue the show
interfaces redundancy command.
To switch from the primary interface to the secondary interface, issue the request
interface switchover amsn command.
To revert to the primary interface from the secondary interface, issue the request
interface revert amsn command.
•
NAT with deterministic IP address and port mapping—Starting in Junos OS Release
14.2R7, you can configure deterministic NAT mapping for NAPT44. Deterministic NAT
mapping ensures that a given internal IP address and port are always mapped to the
same external IP address and port, and the reverse mapping of a given translated
external IP address and port are always mapped to the same internal IP address.
Deterministic NAT mapping eliminates the need for logging address translations.
Configure deterministic NAT translation in a NAT rule by including the translation-type
deterministic-napt44 statement at the [edit services nat rule rule-name term term-name
then translated] hierarchy level.
Configure the range low value to be at least 1024 and the range high value to be no
more than 65,535 at the [edit services nat pool pool-name port] hierarchy level. If you
configure any ports below 1024, they are readjusted.
You can configure up to 64,512 ports to make available for each internal subscriber
with the deterministic-port-block-allocation block-size block-size statement at the [edit
services nat pool pool-name port] hierarchy level. If you do not include this statement,
the default value is 512. If you configure the block-size as 0, Junos OS automatically
calculates the block size by using the number of configured subscriber IP addresses,
the number of external translated IP addresses, and the port range.
•
Support for IKE and IPsec Passthrough NAPT-44 and NAT64 (MX Series routers
with MS-MPCs and MS-MICs)—Starting in Junos OS Release 14.2R7, you can enable
the passing of IKE and IPsec packets through NAPT-44 and NAT64 filters between
IPsec peers that are not NAT-T compliant by using the
IKE-ESP-TUNNEL-MODE-NAT-ALG on MS-MPCs and MS-MICs.
Use the following hierarchy to enable the IKE-ESP-TUNNEL-MODE-NAT-ALG:
[edit applications]
application ike-esp-application-name {
application-protocol ike-esp-nat;
protocol udp;
destination-port 500;
inactivity-timeout 3600;
gate-timeout 90;
child-inactivity-timeout 6000;
}
application-set ike-esp-application-set-name {
application ike-esp-application-name;
}
[edit services nat]
96
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
pool ike-isp-nat-pool-name {
address ip-prefix;
port automatic;
}
rule rule-name {
match-direction input;
term 0 {
from {
source-address address;
application-sets ike-esp-application-set-name;
}
then {
translated {
source-pool ike-isp-nat-pool-name;
translation-type napt-44;
}
}
}
}
•
Class-of-service (CoS) marking and reclassification for the MS-MICs and
MS-MPCs—Starting with Junos Release 14.2R7, the MS-MIC and MS-MPC support CoS
configuration, which enables you to configure Differentiated Services code point (DSCP)
marking and forwarding-class assignment for packets transiting the MS-MIC or
MS-MPC. You can configure the CoS service alongside the stateful firewall and NAT
services, using a similar rule structure.
[See Configuring CoS Rules.]
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 260.]
Copyright © 2016, Juniper Networks, Inc.
97
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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.]
Software Installation and Upgrade
•
Validate system software against running configuration on remote host—Beginning
with Junos OS Release 14.2R5, you can use the on (host host <username username> |
routing-engine routing-engine) option with the request system software validate
package-name command to verify candidate system software against the running
configuration on the specified remote host or Routing Engine.
•
Validate system software add against running configuration on remote host or
routing engine—Beginning with Junos OS Release 14.2R5, you can use the
validate-on-host hostname and validate-on-routing-engine routing-engine options with
the request system software add package-name command to verify a candidate software
bundle against the running configuration on the specified remote host or Routing
Engine.
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.
98
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
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.]
•
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
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.
Copyright © 2016, Juniper Networks, Inc.
99
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[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
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.]
100
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
Global support for LAC forwarding of subscriber line information (MX
Series)—Starting in Junos OS Release 14.2, you can configure the LAC to forward
subscriber line information and optionally to include the Connection Speed Update
Enable AVP (98) for all destinations with the access-line-information statement at
the [edit services l2tp] hierarchy level. In earlier releases, you can configure this only
on a per-destination basis. Both the global and per-destination configurations are
disabled by default.
The global and per-destination settings interact in the following way:
•
Access line information—You can enable forwarding at the global or per-destination
level. When forwarding is enabled globally, you cannot disable the global setting for
a specific destination.
•
Connection speed updates—You can enable updates at the global or per-destination
level. You can disable the global setting for a specific destination by specifying
access-line-information for the destination and omitting connection-speed-update.
[See Subscriber Access Line Information Forwarding by the LAC Overview.]
•
Support for up to 256 L2TP tunnel groups (MX Series)—Starting in Junos OS Release
14.2R5, you can configure and commit up to 256 tunnel groups. In earlier releases, the
CLI prevents you from committing the configuration when you create more than 32
groups.
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
Copyright © 2016, Juniper Networks, Inc.
101
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
•
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
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.
•
102
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)
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
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:
•
•
Related
Documentation
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
endpoints within the context of the overlay VXLAN Network Identifier or VXLAN
Segment ID (VNI) segment.
•
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 104
•
Known Behavior on page 119
•
Known Issues on page 121
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
Copyright © 2016, Juniper Networks, Inc.
103
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Product Compatibility on page 260
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.2R7 for the M Series,
MX Series, and T Series.
•
High Availability (HA) and Resiliency on page 104
•
Interfaces and Chassis on page 105
•
Layer 2 VPNs on page 106
•
MPLS on page 106
•
Multicast on page 107
•
Network Address Translation (NAT) on page 108
•
Network Management and Monitoring on page 108
•
IPv6 on page 108
•
Layer 2 Features on page 108
•
Routing Policy and Firewall Filters on page 109
•
Routing Protocols on page 109
•
Security on page 111
•
Services Applications on page 113
•
Subscriber Management and Services on page 116
•
User Interface and Configuration on page 118
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.]
104
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
•
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}
user@host> 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
•
Distributed denial-of-service protection policer added for system log messages (MX
Series)—Starting in Junos OS Release 14.2, a new protocol-group policer is available
for system log messages. This aggregate policer controls UDP traffic on port 6333,
where the system log server runs on a Routing Engine. In a network where the local
Routing Engine is the system log server, you can use this policer to control the rate at
which system log messages reach the Routing Engine. You can configure values
appropriate for your network environment at the [edit system ddos-protection protocols
syslog aggregate] hierarchy level. The syslog policer is enabled by default, with a default
bandwidth of 2000 packets per second and a default burst of 10,000 packets.
•
Support for LLDP frames on management interfaces (MX Series)—Starting with
Junos OS Release 14.2, LLDP protocol can be enabled on management interfaces (fxp0
and me0) by including the interface interface-name statement or the interface all
statement at the [edit protocols lldp] and [edit routing-instances routing-instance-name
protocols lldp] hierarchy levels. The outputs of various LLDP show commands have
been enhanced to display the LLDP specific local and remote neighbor information on
these management ports, if LLDP is enabled on these ports.
•
Support for auto-10m-100m speed option on Tri-rate MIC (MX Series)— In Junos OS
Release 14.2R7, a new option—auto-10m-100m— is introduced (for the speed statement)
to allow the fixed tri-speed port to autonegotiate with ports that support a maximum
of 100 Mbps or 10 Mbps. When you configure the speed auto-10m-100m statement on
the Tri-rate MIC, it advertises only 10 Mbps and 100 Mbps speeds. The MIC then
autonegotiates either speed on the basis of peer port advertisement.
This option is supported on MX Series routers with Tri-rate MICs (model number:
MIC-3D-40GE-TX) only.
•
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
Copyright © 2016, Juniper Networks, Inc.
105
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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.
•
106
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
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
is disabled with the no-transit-statistics statement at the [edit protocols mpls statistics]
hierarchy level.
This issue was being tracked by PR984000.
[See statistics.]
Multicast
•
Change to show pim join summary command—Starting in Junos OS Release 14.2, the
XML output of the show pim join summary command has changed. The new CLI output
introduces an extra XML hierarchy to separate the tags with the same name.
user@host> show pim join summary | display xml
[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>
Copyright © 2016, Juniper Networks, Inc.
107
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
Layer 2 Features
•
108
Support for configuring MAC move parameters globally (MX Series)—Starting in
Junos OS Release 14.2R7, you can configure parameters for media access control
(MAC) address move reporting by including the global-mac-move statement and its
substatements at the [edit protocols l2-learning] hierarchy level. When a MAC address
appears on a different physical interface or within a different unit of the same physical
interface and this behavior occurs frequently, it is considered a MAC move. You can
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
configure the router such as to report a MAC address move based on the following
parameters: the number of times a MAC address move occurs, a specified period of
time over which the MAC address move occurs, and specified number of times a MAC
address move occurs in one second.
•
Support for bridge domain MAC move action in MX104 router—Starting with Junos
OS Release 14.2, the enable-mac-move-action statement is supported in MX104 router.
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
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
Copyright © 2016, Juniper Networks, Inc.
109
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
for IPv4 and IPv6 interfaces that belong to the same IS-IS instance are not automatically
created. To enable BFD on IPv4 and IPv6 interfaces configured on the same IS-IS
instance, you must also include the new bfd-per-address-family statement at the [edit
protocols isis interface interface-name] hierarchy level. When BFD is enabled for both
IPv4 and IPv6 interfaces in a single IS-IS instance, a BFD session is created for each
protocol family interface. If either the IPv4 or IPv6 session fails, the adjacency is torn
down.
[See Example: Configuring BFD for IS-IS.]
•
Introduction of the all keyword to prevent accidental execution of certain clear
commands—The all keyword is introduced in Junos OS Release 14.2 (as an optional
keyword). This makes users explicitly select the all keyword to clear all protocol or
session information. Thus, it prevents accidental clearing or resetting of protocols or
neighbor sessions, which might disrupt network operations.
The all keyword is introduced for the following clear commands:
•
110
•
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.
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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.
[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:
Copyright © 2016, Juniper Networks, Inc.
111
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[edit routing-instances instance-name routing options]
user@host# set aggregate route 0.0.0.0/0 as-path path 1267
•
Changes to distributed denial of service (DDoS) protection protocol groups and
packet types (MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, the
following syntax changes have been made:
•
•
Policer
The mlp protocol group has been modified as follows to provide DDoS protection
with full control of the bandwidth:
•
The aging-exc, packets, and vxlan packet types have been removed from the mlp
protocol group.
•
The add, delete, and lookup packet types have been added to the mlp protocol
group. These packets correspond to the MAC learning command codes.
•
The keepalive protocol group has been renamed to tunnel-ka.
•
The firewall-host protocol group and the mcast-copy packet type in the unclassified
protocol groups have been removed from the CLI. They are now classified by the
internal host-bound classification engine on the line card.
Changes to distributed denial of service (DDoS) protection default values for MLP
packets (MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, the
following default bandwidth (pps) and burst (packets) values apply for MLP packets
by line card:
MPC1, MPC2, MPC5, and MPC6
MPC3, MPC4, and FPC5
Bandwidth
Burst
Bandwidth
Burst
aggregate
10,000
20,000
5000
10,000
add
4096
8192
2048
4096
delete
4096
8192
2048
4096
lookup
1024
2048
512
1024
unclassified
1024
1024
512
512
•
•
112
Changes to distributed denial of service (DDoS) protection flow detection defaults
(MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, flow detection
defaults to disabled for the following protocol groups and packet type, because they
do not have typical Ethernet, IP, or IPv6 headers. Global flow detection does not enable
flow detection for these groups and the packet type.
•
Protocol groups: fab-probe, frame-relay, inline-ka, isis, jfm, mlp, pfe-alive, pos, services.
•
Packet type: unclassified in the ip-opt protocol group.
Changes to show ddos-protection protocols command output (MX Series, T4000
with FPC5)—Starting in Junos OS Release 14.2, when you disable DDoS protection
policers on the Routing Engine or on an FPC for a specific packet type, an asterisk is
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
displayed next to that field in the CLI output. For example, if you issue the following
statements:
user@host# set system ddos-protection protocols mlp lookup disable-routing-engine
user@host# set system ddos-protection protocols mlp lookup fpc 1 disable-fpc
the fields are marked as in the following sample output:
user@host> show ddos-protection protocols mlp lookup
Currently tracked flows: 0, Total detected flows: 0
* = User configured value
Protocol Group: MLP
Packet type: lookup (MLP lookup request)
Individual policer configuration:
Bandwidth:
1024 pps
...
Routing Engine information:
Bandwidth: 1024 pps, Burst: 2048 packets, disabled*
Policer is never violated
Received: 0
Arrival rate:
0 pps
Dropped:
0
Max arrival rate: 0 pps
Dropped by aggregate policer: 0
FPC slot 1 information:
Bandwidth: 100% (1024 pps), Burst: 100% (2048 packets), disabled*
Policer is never violated
Received: 0
Arrival rate:
0 pps
Dropped:
0
Max arrival rate: 0 pps
Dropped by aggregate policer: 0
Dropped by flow suppression: 0
Services Applications
•
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
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
Copyright © 2016, Juniper Networks, Inc.
113
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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)
114
•
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
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
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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).
•
Changes to distributed denial of service (DDoS) protection protocol groups and
packet types (MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, the
following syntax changes have been made:
•
•
Policer
The mlp protocol group has been modified as follows to provide DDoS protection
with full control of the bandwidth:
•
The aging-exc, packets, and vxlan packet types have been removed from the mlp
protocol group.
•
The add, delete, and lookup packet types have been added to the mlp protocol
group. These packets correspond to the MAC learning command codes.
•
The keepalive protocol group has been renamed to tunnel-ka.
•
The firewall-host protocol group and the mcast-copy packet type in the unclassified
protocol groups have been removed from the CLI. They are now classified by the
internal host-bound classification engine on the line card.
Changes to distributed denial of service (DDoS) protection default values for MLP
packets (MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, the
following default bandwidth (pps) and burst (packets) values apply for MLP packets
by line card:
MPC1, MPC2, MPC5, and MPC6
MPC3, MPC4, and FPC5
Bandwidth
Burst
Bandwidth
Burst
aggregate
10,000
20,000
5000
10,000
add
4096
8192
2048
4096
delete
4096
8192
2048
4096
lookup
1024
2048
512
1024
unclassified
1024
1024
512
512
•
•
Changes to distributed denial of service (DDoS) protection flow detection defaults
(MX Series, T4000 with FPC5)—Starting in Junos OS Release 14.2, flow detection
defaults to disabled for the following protocol groups and packet type, because they
do not have typical Ethernet, IP, or IPv6 headers. Global flow detection does not enable
flow detection for these groups and the packet type.
•
Protocol groups: fab-probe, frame-relay, inline-ka, isis, jfm, mlp, pfe-alive, pos, services.
•
Packet type: unclassified in the ip-opt protocol group.
Changes to show ddos-protection protocols command output (MX Series, T4000
with FPC5)—Starting in Junos OS Release 14.2, when you disable DDoS protection
Copyright © 2016, Juniper Networks, Inc.
115
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
policers on the Routing Engine or on an FPC for a specific packet type, an asterisk is
displayed next to that field in the CLI output. For example, if you issue the following
statements:
user@host# set system ddos-protection protocols mlp lookup disable-routing-engine
user@host# set system ddos-protection protocols mlp lookup fpc 1 disable-fpc
the fields are marked as in the following sample output:
user@host> show ddos-protection protocols mlp lookup
Currently tracked flows: 0, Total detected flows: 0
* = User configured value
Protocol Group: MLP
Packet type: lookup (MLP lookup request)
Individual policer configuration:
Bandwidth:
1024 pps
...
Routing Engine information:
Bandwidth: 1024 pps, Burst: 2048 packets, disabled*
Policer is never violated
Received: 0
Arrival rate:
0 pps
Dropped:
0
Max arrival rate: 0 pps
Dropped by aggregate policer: 0
FPC slot 1 information:
Bandwidth: 100% (1024 pps), Burst: 100% (2048 packets), disabled*
Policer is never violated
Received: 0
Arrival rate:
0 pps
Dropped:
0
Max arrival rate: 0 pps
Dropped by aggregate policer: 0
Dropped by flow suppression: 0
•
Support for deterministic NAPT (MX Series)—You can configure deterministic port
block allocation for Network Address Port Translation (NAPT) on MX Series routers
with MS-MPCs or MS-MICs. By configuring deterministic NAPT, you ensure that
translation of internal host IP(private IP to public IP and vice versa) is deterministic
thus eliminating the need for address translation logging for each connection. To use
deterministic port block allocation, you must specify deterministic-napt44 as the
translation type in your NAT rule.
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.
116
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
•
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.
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.
Copyright © 2016, Juniper Networks, Inc.
117
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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
118
•
New and Changed Features on page 65
•
Known Behavior on page 119
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
•
Known Issues on page 121
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
Known Behavior
This section contains the known behavior, system maximums, and limitations in hardware
and software in Junos OS Release 14.2R7 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.
•
Hardware on page 119
•
High Availability (HA) and Resiliency on page 119
•
MPLS on page 120
•
Network Management and Monitoring on page 120
•
Routing Protocols on page 120
•
Software-Defined Networking (SDN) on page 120
•
Subscriber Management and Services on page 120
•
System Logging on page 121
•
VPNS on page 121
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
Copyright © 2016, Juniper Networks, Inc.
119
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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, 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
•
120
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.
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
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.
•
Subscriber management is not supported when the routing protocol daemon (rpd) is
running in 64-bit mode. For subscriber management support, rpd must run in 32-bit
mode.
System Logging
•
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.
VPNS
•
Default export EVPN policy has been removed (MX Series)—Starting in Junos OS
Release 14.2R7 and forward, the hidden default EVPN export policy statement
(evpn-pplb) has been removed. To enable and configure load balance per packet for
EVPN and PBB-EVPN, use the existing policy statements:
•
set routing-options forwarding-table export evpn-pplb
•
set policy-options policy-statement evpn-pplb from protocol evpn
•
set policy-options policy-statement evpn-pplb then load-balance per-packet
NOTE: To support EVPN multihoming, you must configure the load-balance
per-packet statement.
Related
Documentation
•
New and Changed Features on page 65
•
Changes in Behavior and Syntax on page 104
•
Known Issues on page 121
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R7
for the M Series, MX Series, and T Series.
Copyright © 2016, Juniper Networks, Inc.
121
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
For the most complete and latest information about known Junos OS defects, use the
Juniper Networks online Junos Problem Report Search application.
•
Class of Service (CoS) on page 122
•
Forwarding and Sampling on page 122
•
General Routing on page 123
•
High Availability (HA) and Resiliency on page 128
•
Infrastructure on page 128
•
Interfaces and Chassis on page 128
•
J-Web on page 130
•
Layer 2 Features on page 131
•
Layer 2 Ethernet Services on page 131
•
MPLS on page 131
•
Network Management and Monitoring on page 132
•
Platform and Infrastructure on page 133
•
Routing Protocols on page 135
•
Services Applications on page 136
•
Subscriber Access Management on page 137
•
User Interface and Configuration on page 138
•
VPNs on page 138
Class of Service (CoS)
•
When the egress rewrite rules are assigning to both the underlying interface and the
subscriber interface, the rewrite rule applied to the underlying interface may take
precedence and the priority values are applied as set at that level, which is wrong. The
rewrite rule applied to the subscriber interface should take effect over the underlying
interface. PR1058372
Forwarding and Sampling
•
When VRRP is configured on Trio-based MX interfaces, Static mac entries are installed
on Packet Forwarding Engine 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
•
OID .1.3.6.1.2.1.2.2.1.2 stops responding after upgrading Junos OS from 11.4X27 to 13.3R5.9.
PR1072841
•
122
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),
Copyright © 2016, Juniper Networks, Inc.
Known Issues
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
•
If bandwidth-percent based policer is applied on aggregated Ethernet (AE) bundle
without the "shared-bandwidth-policer" configuration statement, traffic will hit policer
even if the traffic is not exceeding the configured bandwidth. As a workaround, configure
the "shared-bandwidth-policer" configuration statement under the policer. PR1125071
•
Firewall filter-list configured of inet and inet6 applied on same ifl under inet and inet6
family input-list. Functionality-wise no issue and the CLI command "run show firewall"
shows correct statistics for both filters lists configured for inet and inet6 families. Here
the limitation arrived with the day-one implementation of filter-list renaming logic.
Both inet and inet6 filter list configured will have the same name, refer to
http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/firewal
l-filter-option-multiple-listed-overview.html . The system will have two filters with the
same name. Due to this, in SNMP MIB will handle only any one of this filter-list stats
and report when fetched. Concluding: When input-list/output-list filters applied under
different families of same ifl, then only one of the filter-list family counters can be
shown in SNMP MIB walk of firewall counter table. PR1173332
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
•
The IFL count is incorrect and will not be repaired until a PIC restart. PR882406
•
Kernel messages "SO_RTBL_INDEX " are seen continuously when LDP session is down.
The log messages were meant for debugging purpose and are harmless.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
With "chassis maximum-ecmp 64" configured, when there is a route having 64 ECMP
LSP next-hops and CoS-based forwarding (CBF) is enabled with 8 forwarding class
(64*8=512 next-hops), not all next-hops will be installed on Packet Forwarding Engine
due to crossing the boundary in the kernel when number of ECMP next-hops is larger
than 309. PR917732
•
On Junos OS 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
Copyright © 2016, Juniper Networks, Inc.
123
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
There is a 50 Kpps drop in performance due to addition of new functionality over
previous release. PR935393
•
In MX Virtual Chassis (MX-VC) environment, the private local nexthops and routes
pointing to private local nexthops are sent to Packet Forwarding Engine from master
Routing Engine and not sent to slave Routing Engine, then an Routing Engine switchover
happens. Now as the new master Routing Engine does not know about such nexthops
and routes, they are not cleaned up. When a nexthop with same index is added on new
master Routing Engine and sent to Packet Forwarding Engine, the Packet Forwarding
Engine might crash due to a stale nexthop. PR951420
•
OVSDB/NSX: NSX controller does not delete stale VTEP+MAC information. 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 Routing Engine switchover occurs,
after that execute the command "root@user> show dynamic-configuration" many
times, large-scale DHCP or DHCPv6 subscribers might be terminated. PR968021
•
Openflow 1.3: packet was not received on interface after restart firewall daemon.
PR969520
•
If the ICMP echo response is sent with a wrong sequence number, flow lookup passes
and the counter gets incremented, but the packet is discarded by the ICMP ALG.
PR971871
124
•
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
•
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
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
Some intermediate hostnames that are displayed incorrectly for the MTR (My
traceroute) utility with NAPT44. Traceroute utility works fine. PR1008088
•
On MX Series routers with MPC3E, MPC4E, MPC5E, MPC6E, Junos OS does not support
short (sub-second) interface hold-time down configuration. So, a hidden configuartion
statement is introduced to ignore DFE tuning state during hold-down timer period. This
configuration statement allows sub-second hold-down timer on MPC3E, MPC4E,
MPC5E, MPC6E. set interfaces <intf name> hold-time up <U ms> down <D ms>
alternative The configuration statement does not work/support 'MPC5E 3D Q
2CGE+4XGE' and 'MIC6 2X100GE CFP2 OTN', and we recommend configuring hold-time
down to be more than 3 seconds for these two cards. PR1012365
•
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 Packet Forwarding Engine and it can trigger data events
(IIF-MISMATCH) that can create undesirable (S,G) states. These states are usually
harmless but, in a high scale, can result in resource utilization. It is worth noting that in
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
•
On Offline/Online cycle of a 40GE QSFP card, a 40GE interface port's Physical Link
might remain down. Few events which will result into the Offline/Online cycle of a
40GE QSFP card are router reboot, FPC reboot, or chassis-control restart or 40GE Card
offline request followed by a 40GE Card online request. PR1026088
•
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
•
When ps interface is configured using as anchor interface a logical tunnel (lt) interface
without explicit tunnel-bandwidth configuration (under 'chassis fpc <fpc-number>
pic <pic-number> tunnel-services' configuration hierarchy), the ps interface is created
only in kernel, but not on Packet Forwarding Engine. In order to have ps interface in
Packet Forwarding Engine, an explicit tunnel-bandwidth configuration is required. PR
1042737 removes this restriction, and a ps interface may be anchored to an lt interface
without explicit tunnel-bandwidth configured. PR1042737
•
On dual Routing Engine platform, when performing unified graceful Routing Engine
switchover (GRES) or graceful restart (GR) on the device, due to the fact that some
part of the code may not be executed on Routing Engine, the Routing Engine may get
into DB prompt state. PR1052330
•
In configurations with IRB interfaces, during times of interface deletion, such as an FPC
reboot, the Packet Forwarding Engine may log errors stating
"nh_ucast_change:291Referenced l2ifl not found". This condition should be transient,
with the system re-converging on the expected state. PR1054798
•
Log message that request upgrade of VSC8248 firmware of MPC3/MPC4 is displayed
during Junos upgrade. PR1058184
Copyright © 2016, Juniper Networks, Inc.
125
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
With inline L2TP IP reassembly feature configured, the MX Series routers with
MPCs/MICs might crash due to a memory allocation issue. PR1061929
•
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
•
Wrong byte count was seen in the ipfix exported statistics packets for mpls flows . This
issue is taken care of now . PR1067084
•
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
•
During ISSU on MX-VC working as an LAC, few HELLO packets from LNS will go
unanswered, which might cause L2TP tunnel to get torn down. PR1074991
•
In scaled subscriber management environment (for example, 3.2K PPPoE subscribers),
after heavy login/logout, the session setup rate keeps decreasing and also PAP-NAK
messages are sent with "unknown terminate code". This continues untill Broadband
Network Gateway (BNG) does not accept PPP sessions and all newly incoming sessions
are stuck in PAP Authentication phase (no PAP ACK received). PR1075338
•
The Trio-based line card might reboot immediately after restarting l2tp daemon at
L2TP network server (LNS) during login/logout of scaled (e.g., 10k) L2TP clients.
PR1082321
•
Memory leaks will be seen with jnx_msp_jbuf_small_oc object, upon sending millions
of PPTP control connections[3-5M] alone @ higher CPS[> 150KCPS]. This issue is not
seen upto 50K control connections @ 10K-30K CPS. PR1087561
•
There is a bug about expansion memory usage computation. It does not account for
freed memory. So the displayed expansion memory usage is higher than the real
expansion memory usage. As displayed expansion memory usage reaches over the
configured threshold (in this case, the threshold is 95%), subscribers are denied to
come up. As a workaround, we could disable the resource monitoring throttling feature
to avoid possibility incorrect expansion memory usage. PR1090733
•
Dynamic vlan ifl is not removed with 'remove when-no-subscriber' configuration.
PR1106776
•
126
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,
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
Copyright © 2016, Juniper Networks, Inc.
Known Issues
this symptom would also add complexity to routing control plane, hence there's no
plan to fix it. PR1114809
•
The entire set of prefix list needs to be committed in one go. In case new prefix needs
to be added on the fly, all the prefix lists needs to be re-added after deletion so that
all prefix lists are honored. PR1124165
•
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
•
SIP-ALG: In SIP Session, RTCP packets from the public get dropped. This issue is due
to the return flow from the outside triggered session which will conflict with inside
triggered session (forward flow). The workaround is to trigger outside traffic first (initiate
RTCP packet from from outside at first). PR1137615
•
ALG-SIP64: SIP session fails when the IPv4 SIP Client in public network initiates sip
call with the IPv6 SIP client in the private network PR1139008
•
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
•
When a NAT pool is shared among multiple terms, and if "address-pooling paired" is
enabled only in few of those terms (not all), it leads to traffic drop. So, for all terms
sharing a NAT pool, either all of them should have address-pooling paired configured
or none of them should have it configured. PR1161623
•
Traffic may drop during Routing Engine switchover. PR1164107
•
NAT64 service-set:Port block efficiency and Unique pool users stats displays incorrect
value when NAT POOL is modified dynamically with CGNAT traffic for the particular
term in the NAT-rule. PR1177244
•
CGNAT-NAT64: Few port leak are observed for the EIM/EIF IPv4 traffic(2M sessions)
from public side. PR1177679
•
The number of nat-logs generated and the service-set syslog stats does not match.
Service-set stats "show services service-sets statistics syslog service-set <name>”.
PR1177706
•
NAT64: Source-prefix filtering and protocol filtering of the CGNAT sessions are incorrect
For example show services sessions extensive protocol udp source-prefix <0:7000::2>
displays incorrect filtering of the sessions. PR1179922
Copyright © 2016, Juniper Networks, Inc.
127
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
CGNAT-NAT64:All the members of the AMS bundle crashes upon running Ipv6 TCP
stack scrambler + isic6 + mix of ALG [HTTP+FTP] + DNS64 traffic with NAT64
configured. PR1183503
•
Source-address based Filter Based Forwarding is used under forwarding-options to
steer the packets towards AMS bundle in the Vodafone configuration. When we remove
the from source-address condition from the filter, the reverse traffic gets looped back
into the AMS bundle. Under this condition, Prolonged Flow Control cores are seen. We
do have from source-address configured in the SFW rule, which should have dropped
the packets, which are getting looped back into the AMS bundle, but, this is not
happening, even though SFW functionality works as expected for other packets.
PR1192184
•
CGNAT NAT mappings and ports are not cleared after SIP session timeouts for the
SIP spoofed traffic and SIP scaled traffic, and very few ports not released for the scaled
traffic of 10-20K SIP sessions. PR1187965
•
Ingress queuing configuration on MPC2ENG is leading to host loopback wedge due to
some bug in the code specific to MPC2ENG; there is a mis-programming in the Junos
code for the lookup chip for this type of card. PR1189800
High Availability (HA) and Resiliency
•
During a router hardware upgrade procedure, in a dual Routing Engines system, the
newly installed Routing Engine (RE) may overwrite the other Routing Engine
configuration with the factory default configuration. As a result, both Routing Engines
may boot up in "Amnesiac" mode. 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
•
With 64-bit image, when activate the Network Time Protocol (NTP) configuration with
system date set prior to 1981, negative value from ntpd process results in wrong time
settings instead of Real-time clock (RTC), and the router might crash. PR1056669
Interfaces and Chassis
128
•
During an Routing Engine 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
•
Routing Engine 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 links are configured separately
in it in a single commit. PR892129
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
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 will be
removed from the master VRRP router at commit. PR901803
•
Kernel crash may happen when a router running a Junos install with the fix to PR 937774
is rebooted. This 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. This is 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
•
On MX Series-based line cards, in virtual private LAN service (VPLS) environment, the
next hop in the kernel allocated by connectivity-fault management process (cfmd)
may not be freed even after the CFM session has been removed (for example,
deactivating the routing-instance). In this situation, after re-activating the
routing-instance, the interface within the routing instance would fail to come up because
the nexthop is not freed by the cfmd application and hence the VPLS connection is
down. PR1000060
•
On dual Routing Engine platforms, when adding the logical interfaces (IFLs) and
committing, due to the device control process (dcd) on the backup Routing Engine
might fail to process the configuration and keep it in the memory. In some cases (not
happening all the time), it might be observed that the memory of the dcd keeps
increasing on the backup Routing Engine. PR1014098
•
On MX Series platform with large-scale PPPoE subscribers (more than 60k) connected,
PPP client process (jpppd) might crash and generate core files when performing Routing
Engine switchover. PR1018313
•
ISSU is not supported for VRRP sessions running over LT interface. For minimum impact
on traffic during upgrade, user should move the mastership to peer router and then
issue an upgrade. PR1030945
•
When configuring MX Virtual-chassis system, pace the creation of VCP ports. PR1052821
•
During subscriber login/logout, the following error log might occur on the device
configured with GRES/NSR: “/kernel: if_process_obj_index: Zero length TLV! /kernel:
if_Packet Forwarding Engine: Zero length TLV (pp0.1073751222)” PR1058958
•
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
Copyright © 2016, Juniper Networks, Inc.
129
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The following debug message can be seen on the log, but is harmless and no action
needs to be taken: “/kernel: pp0.102132231: ENTERED: calculate_ppp_mru with
lower_mru (1492) ppp_local_mtu = 1492 ppp_cfg_mru = 0 , lower_max_mtu = 9016 ,
pppoe_rwlen = 24, pppoe_ifl_l2hdr_len = 0” PR1074765
•
In a VPLS scenario with specific CE mesh group configured, after a Routing Engine
restart or Routing Engine master switchover, the flood NH for the mesh group might
not be programmed properly. A complete black-holing for the VPLS instance would
be seen as a consequence. PR1087293
•
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
•
To ensure that the router or switch is reachable for management purposes while it
boots or if the routing protocol process fails to start properly, we can configure a backup
router, which is a router that is directly connected to the local router or switch (that is,
on the same subnet) through its private management interface (for example, fxp0 or
me0). When a backup router running IPv6 and a static route to reach the management
network are configured, some invalid IPv6 routes are added to default forwarding-table
on the master or the backup Routing Engine (RE). PR1100981
•
In PPPoE subscriber management environment, when dynamic VLAN subscriber
interfaces are created based on Agent Circuit Identifier (ACI) Information, the
subscribers might unable to log in after reboot FPC with syslog "Dropping PADI due to
no ACI IFLSET". PR1117070
•
In Dynamic PPPoE subscriber management scenario, when the system is overloaded
with requests coming, the subscribers might fail to log in in a race condition. PR1130546
•
The jpppd process might crash and restart due to a buffer overwrite. The jpppd process
restart results in a minimal impact of system and subscribers. All connected subscribers
remain connected and only subscribers are attempting to connect at time of process
restart would need to retry. PR1132373
•
jpppd core at SessionDatabase::getAttribute() from
Ppp::LinkInterfaceMsOper::getLowerInterfaceType(). PR1165543
J-Web
130
•
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
Copyright © 2016, Juniper Networks, Inc.
Known Issues
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 are not affected. The router recovers
quickly and normal operation resumes with the new configuration. PR976972
•
When "input-vlan-map" with "push" operation is enabled for dual-tagged interfaces
in "enhanced-ip" mode, there is a probability that the broadcast, unknown unicast,
and multicast (BUM) traffic may be blackholed on some of the child interfaces of the
egress Aggregated Ethernet (AE) interfaces or on some of the equal-cost multi-path
(ECMP) core-links. PR1078617
Layer 2 Ethernet Services
•
When Routing Engine instructs the FPC to delete a next-hop (NH) which involving PFH
or Packet Forwarding Engine internal interface, the FPC might crash. PR928230
•
When using Link Aggregation Control Protocol (LACP) link protection to protect a
single link in the Aggregated Ethernet (AE) bundle, the lacpd process might crash upon
the configuration changes to AE or LACP. PR1078184
MPLS
•
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
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
•
When "soft-preemption" is enabled on ingress router and the preemption is configured
with "aggressive" option to preempt RSVP sessions whenever bandwidth is lowered
or a new higher-priority session is established, if one LSP is established over AE
Copyright © 2016, Juniper Networks, Inc.
131
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
(aggregation Ethernet) interface, in case of link failure to cause the bandwidth
insufficient at the ingress, the CSPF is not triggered, owing to missing data in TED, to
establish a new path for more than 30 seconds and eventually the LSP is hard
preempted. PR1030586
•
When using "mpls traffic-engineering bgp-igp-both-ribs" with LDP and RSVP both
enabled, CSPF for inter-domain RSVP LSPs cannot find the exit ABR when there are
2 or more such ABRs. This causes inter-domain RSVP LSPs to break. RSVP LSPs within
same area are not affected. Workarounds are: run RSVP only on OSPF ABR or ISIS
L1/L2 routers and switch RSVP off on other OSPF area 0/ISIS L2 routers; or don't use
LDP at all, use only RSVP. PR1048560
•
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
•
LDP route delete is always communicated to resolver before resolver unresolves BGP
nexthop via LDP tunnel. In this particular scenario which seems to stress the Junos
routing deamon, LDP route delete happens but resolver is yet to know about it. And
resolver access the deleted LDP route entry. This leads resolver to access LDP route
pointer that is already freed and leads to RPD core. PR1097642
•
These benign error messages can be ignored. The Junos OS code will be cleaned up
to remove these messages in later code. PR1136033
•
In a p2mp LSP setup, such that an ingress LER is running a pre-14.1R1 image and the
egress is running a post-14.1R1 image, the p2mp LSP may not come up. In such a
situation the provided workaround (to be enabled on the egress router), allows the
p2mp LSP to come up. PR1160549
Network Management and Monitoring
132
•
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
Copyright © 2016, Juniper Networks, Inc.
Known Issues
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
•
When scripts are synchronized from one Routing Engine to the other, the destination
for the scripts in the other Routing Engine should be based on the configuration on the
other Routing Engine. This issue prevents this from happening and destination for
scripts depends on the current Routing Engine from which the scripts were synchronized
instead of the configuration on the other Routing Engine. PR841087
•
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
•
Kernel messages "SO_RTBL_INDEX " are seen continuously when LDP session is down.
The log message were meant for debugging purpose. It is 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
•
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
•
On MX Series platform, while configuring the option 125, CLI does not accept all the
hexadecimal characters. PR965368
•
A defect in L3VPN Make Before Break code was resulting in freeing memory
corresponding to old nexthops which is being used by egress Packet Forwarding Engine.
This was resulting in memory corruption. PR971821
•
In the dual Routing Engine’s scenario, the backup Routing Engine does not sync up the
configuration change while deleting an inactivated interface from the master. So after
the operation, the inactivated interface still exists on the backup Routing Engine.
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
Copyright © 2016, Juniper Networks, Inc.
133
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The rate-limit value does not match between Routing Engine and Packet Forwarding
Engine. PR1023809
•
When upgrading from 13.3R3 to 14.2, users may notice a tnetd core after the upgrade.
This core file is harmless and does not affect operation of the platform or software in
any way. PR1025287
•
MSDPC-HTTP redirect stops working. PR1039849
•
Once the Traffic Offload Engine (TOE) thread is stalled due to memory error at the
lookup chip, all statistics collection from the interfaces hosted by this Packet Forwarding
Engines are not updated anymore. PR1051076
•
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'. A Packet Forwarding Engine 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
•
Prior to the fix, Juniper VSA length above 2K bytes is not supported. Using authorization
parameters above this length would result in wrong authorization setting for the user.
PR1072356
134
•
On Trio-based line cards, when the firewall filters with prefixes are configured, the
heap memory leak issue might be observed. PR1073911
•
When deleting some uncommitted configuration on active Routing Engine, the rpd
process on backup Routing Engine might restart due to "Unable to proceed with commit
processing due to SIGHUP not received. Restarting to recover". PR1075089
•
In XM based multi LU systems (MX platform with
MPC3E/MPC4E/MPC5E/MPC6E/NG-MPC3/NG-MPC2 or T4000 with T4000-FPC5-3D
linecard), we have multiple LUs representing the same Packet Forwarding Engine
complex, we designate the BFD processing to a dedicated LU (LU 0), called as anchor
LU, the rest of the LUs (LU 1, LU 2, LU 3) are called non-anchor LUs. When the Inline
BFD packets punts from non-anchor LU to the anchor LU, it does not have the
'interface-group' populated in the packet context, so the packets might not be matched
by related filter term. PR1084586
•
When the large scale firewall filter (e.g., with 10K terms on input/output) is configured
on either FPC5 or MPC3/4/5/6, traffic drop may occur due to allocation limit. PR1093275
•
Preventing an issue where one could end up with two junos:comment entries under the
[interfaces] stanza. PR1102086
•
The kernel next-hop acknowledgement timeout maximum interval configured
(krt-nexthop-ack-timeout) under the CLI hierarchy "routing-options forwarding-table"
Copyright © 2016, Juniper Networks, Inc.
Known Issues
has been increased to 400 seconds to avoid performance issues with scaled subscribers.
PR1102346
•
Improved VTY commands to show internal JNH memory usage. PR1103660
•
On Trio-based platform, in MX Series Virtual Chassis (MXVC) environment, if the
subscriber logical interface (IFL) index 65793 is created (for example, when carrying
15K DHCPv4 subscribers to exceed IFL index creation 65793) and the IEEE 802.1p
rewrite rule is configured (for example, using CoS rewrite rules for host outbound
traffic), due to usage of incorrect IFL index, the Virtual Chassis Control Protocol Daemon
(vccpd) packets (for example, Hello packets) transmission may get lost on all VC
interfaces, which may lead to VC decouple (split brain state, where the cluster breaks
into separate parts). As a workaround, either delete the rewrite rule (delete
class-of-service host-outbound-traffic ieee-802.1 rewrite-rules), or find the IFL in jnh
packet trace that is not completing the vccpd send to other chassis and at Routing
Engine clear that subscriber interface may resolve the issue. PR1105929
•
In the Trio base linecard environment with inline sampling service, after FPC reboot, in
rare condition, the traffic forwarding might get affected as the PFEMAN SRRD thread
consumes high CPU in this case continuously. PR1141814
•
On ungraceful exit of telnet (quit/shell logout), perm and env files created by pam
were not deleted. PR1142436
•
The jtree will corrupt which will cause router can't forward traffic after interface flaps
when OSPF LFA is configured and no load-balance policy is configured. PR1169468
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 Routing
Engine 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
•
In a BGP scenario with IPv4 and IPv6 neighbors co-exist in the same group, if all of the
IPv4 peers flap 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
•
There was a bug in the code path for 'show route resolution' which was causing an
extra decrement of the refcount in the show handling. This was causing an early free
of some shared object and hence causing a crash. PR995170
Copyright © 2016, Juniper Networks, Inc.
135
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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
•
When configuring router in RR mode (cluster-id or option B MP-eBGP peering), the
advertise-external feature will not be applicable in local VRFs due to a different route
selection/advertisement process (main bgp.l3vpn.0 vs VRF.inet.0). PR1023693
•
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
•
Junos OS exhibits two different next-hop advertisement behaviors for MP_REACH_NLRI
on a multi-hop eBGP session, based on whether it is loopback peering or physical
interface peering. When the routers are peering on their loopback, only the global IP
of the interface (lo0) is advertised, whereas when the routers are peering through the
physical interface, both global and link-local address are advertised as the NHs.
PR1115097
•
When multiple addresses are configured on an interface, if the interface has
"interface-type p2p" configured under OSPF and the router does not receive any OSPF
packets from one of the IFAs, the OSPF state will not go down for the corresponding
adjacency. It should have no impact on route learning, but it might cause confusion for
troubleshooting, when peering with Cisco devices, which have multiple addresses
configured as secondary addresses. PR1119685
•
Generate route doesn't inherit the next-hop from the contributing route in L3VPN case
when the contributing route is learnt via MP-BGP. The next-hop remains as reject for
the generated route. PR1149970
•
In dual Routing Engines scenario with NSR and PIM configuration, when backup Routing
Engine handling mirror updates about PIM received from the master Routing Engine,
it will delete the PIM session info from its database. But due to a software defect, a
leak of 2 memory blocks (8 or 16 byte leaks) will occur for every PIM leave. If the memory
is exhausted, the rpd process might crash on backup Routing Engine. There is no impact
seen on the master Routing Engine when the rpd cores on backup. PR1155778
•
Inet6.1 table is removed from the router. PR1183419
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 and 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 them, which eventually causes the client FTP time out.
PR972402
136
Copyright © 2016, Juniper Networks, Inc.
Known Issues
•
In the NAT environment, the jnxNatSrcPoolName OID is not implemented in
jnxSrcNatStatsTable. PR1039112
•
With scaling Layer 2 Tunneling Protocol (L2TP) sessions (for example, 128k sessions),
when executing L2TP "show" command in one terminal and "clear" command in
another terminal simultaneously, pressing Ctrl-C or closing the terminal on one terminal
might cause the jl2tpd process crash. PR1063207
•
With majority of L2TP subscribers log in with invalid credentials (75% of new login
requests are invalid), low call setup rate (CSR) will be observed for the good login
attempt subscribers. PR1079081
•
If l2tp is configured under access-group hierarchy, during commit or commit check
operation, the pppd process might crash (the configuration could commit successfully).
It might result in a minimal impact of system, and it will restore automatically. As a
workaround, please configure the same under the access profile client hierarchy.
PR1108024
Subscriber Access Management
•
On BNG router, When the router is processing session "idle timeout", the following
error message might be seen:
“./../../../../src/junos/usr.sbin/authd/acc/authd_aaa_acc.cc:1273 Failed to process the
Idle Timeout for session-id:10” Please note it will not affect any services. PR1041654
•
When using Neighbor Discovery Router Advertisement (NDRA) and DHCPv6 prefix
delegation over PPPoE in the subscriber access network, if a local pool is used to
allocate the NDRA prefix, when the CPE send DHCPv6 solicit message with both
Internet Assigned Numbers Authority (IANA) and Identity Association Prefix Delegation
(IAPD) options, the subscriber might get IPv6 prefix from the NDRA pool but not the
delegated pool. As a workaround, the CPE should send DHCPv6 solicit message with
only IAPD option. PR1063889
•
Subscriber is not coming up when Cisco AVPair VSA value is returned in Radius
ACCESS-ACCEPT packets in certain scenarios. PR1074992
•
On MX Series platform, when using the DHCPv6 prefix delegation over PPPoE, if the
RADIUS allocates a DHCPv6 pool name during the authentication of subscribers and
"on-demand-ip-address" feature is enabled in a dynamic-profile, the prefixes may not
be cleared by authentication process (authd) after disconnecting the subscribers.
PR1108038
•
For scenarios that are not in a Layer 3 wholesale network environment, we can configure
"duplication-vrf" to send duplicate accounting records to a different set of RADIUS
servers that reside in either the same or a different routing context. After Routing Engine
switchover, the duplicate accounting feature stops working for existing subscribers.
PR1121524
•
In subscriber management environment with AAA authentication, after a few rounds
of login/logout, some dynamic PPPoE subscribers might get stuck in configured
(AuthClntLogoutRespWait) state. PR1127823
Copyright © 2016, Juniper Networks, Inc.
137
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 J-Web. PR888714
•
Basic value entry format error check is not present in Configure-->Security-->IPv6
Firewall Filters, but the same is present in IPv4 Firewall Filters. But it will throw error
when try to commit the wrong format data entered. PR1009173
VPNs
Related
Documentation
138
•
(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
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
•
New and Changed Features on page 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Resolved Issues on page 139
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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.2R7 on page 139
•
Resolved Issues: 14.2R6 on page 153
•
Resolved Issues: 14.2R5 on page 171
•
Resolved Issues: 14.2R4 on page 195
•
Resolved Issues: 14.2R3 on page 216
•
Resolved Issues: 14.2R2 on page 234
Resolved Issues: 14.2R7
General Routing
•
DPD may not work with link-type IPSec tunnels when NAT is present between the
IPSec peers. Even when NAT is not present between the IPsec peers, the issue can
occur with lesser probability. PR895719
•
In MX Virtual Chassis (MX-VC) environment, the private local next hops and routes
pointing to private local next hops are sent to thePacket Forwarding Engine from master
Routing Engine and not sent to slave Routing Engine, then an Routing Engine switchover
happens. Now, as the new master Routing Engine does not know about such next hops
and routes, they are not cleaned up. When a next hop with same index is added on
new master Routing Engine and sent to Packet Forwarding Engine, the Packet
Forwarding Engine might crash due to a stale next hop existing. PR951420
•
An EVPN with support for inter-subnet routing using an irb interface may experience
a crash and restart of rpd, leaving a core file for analysis. In this case, EVPN MAC routes
contain MAC+IP, and this IP/32 is installed in VRF table on egress router. Core is
triggered in the IP/32 route installation flow. There is no special trigger point- it's a
timing issue with basic irb configurations. PR992059
•
The L2ald may crash after interface flap. PR1015297
•
In IP security (IPsec) VPN environment, after performing the RE switchover, the traffic
may fail to be forwarded due to the SAs may not be downloaded to the PIC, or due to
some security associations (SAs) on the PIC may incorrectly hold references for old
Security Policy Database (SPD) handles while SPD has deleted its entries in the Security
Association Database (SAD). PR1047827
•
PCE-initiated LSPs are less preferred than locally configured LSPs. After this issue is
fixed, PCE-initiated LSPs will have same preference as locally configured LSPs.
PR1075559
•
Junos OS runs PKId for certificate validation. When a peer device presents a self-signed
certificate as its end entity certificate with its issuer name matching one of the valid
CA certificates enrolled in Junos, the peer certificate validation is skipped and the peer
Copyright © 2016, Juniper Networks, Inc.
139
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
certificate is treated as valid. This may allow an attacker to generate a specially crafted
self-signed certificate and bypass certificate validation. Refer to JSA10755 for more
information. PR1096758
140
•
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
•
On MX Series routers where MS-MIC or MS-MPC is inserted, certain combinations of
fragmented packets might lead to an MS-MIC or MS-MPC coredump. PR1102367
•
In rare condition, after Routing Engine switchover, - the MPC PIC might offline, and
some error messages might be seen. - at times chassisd on Routing Engine goes to
continuous coring makes unit unusable as none of interfaces come up. Root cause:
After Routing Engine switch over chassisd fail to get proper status of the FPCs and
cores due to insufficient IDEEPROM read times. PR1110590
•
If a static or protocol learned 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
•
For scaled configuration, it may take too much time for commit and session gets hung
because there is an unnecessary check to see if family Ethernet-switching co-exists
with family bridge for all interfaces having bridge configuration. PR1122863
•
RPD crash might be seen during deletion of address family on an interface while rpf
check is configured. PR1127856
•
The speed konb auto-10m-100m allows to auto negotiate the speed maximum to
100mbps. PR1155196
•
CE in an EVPN setup which has no-mac-learning or is otherwise forwarding traffic
upstream to MX's in an Active/Active EVPN configuration will see split horizon broken
by the MX PE which has the MAC as DRC status. PR1156187
•
After MIC "MIC-3D-4OC3OC12-1OC48" reboot, we might see below logs filling syslog
message : router-re0 fpc2
cc_mic_sfp_is_present:?????????????????????????????????????????????????????
?????????????????????????^^??^P-sM-^T^S?? - Device is not SFP type
router-re0 fpc2 cc_mic_sfp_periodic: Link 0 SFP - plugged in. router-re0 fpc2
cc_mic_sfp_is_present:?????????????????????????????????????????????????????
?????????????????????????^^??^P-sM-^T^S?? - Device is not SFP type [LOG:
Err]
cc_mic_sfp_is_present:?????????????????????????????????????????????????????
?????????????????????????5?x??l?8 - Device is not SFP type [LOG: Err]
cc_mic_sfp_is_present:?????????????????????????????????????????????????????
?????????????????????????5?x??l?8 - Device is not SFP PR1156353
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Given an active BGP multipath route with 2+ Indirect-Next-Hops and another BGP
route which can participate in protocol independent multipath with router-next-hop,
rpd might crash if the interface on which first member of Indirect-Next-Hop resolves
goes down. PR1156811
•
A previous enhancement to strengthen the VC-Heartbeat message exchange resulted
rejecting messages at the crucial time of determining the health of the other VC member
when all adjacency links fail. Validation of messages has been adjusted to remain
strong when the VC is connected, but relaxed during the split conditions to prevent
rejecting valid messages. PR1157383
•
On MX Series platform supporting MPC3E or MPC4E type MPC, the single-hop BFD
session configured under a routing-instance (RI) can flap intermittently. The problem
would be seen when the main-instance loopback firewall filter discards/rejects the
BFD packets OR has term to accept only BFD packets from neighbors configured under
main instance. In both scenarios, the BFD session packets coming on routing-instance
will be wrongly matched to main-instance loopback filter and gets discarded. With
the fix of this issue, this situation is avoided and BFD session packets from
routing-instance will be matched with the correct RI loopback filter (if configured).
Note: In case there is no RI loopback interface configured, then BFD packets are matched
against main-instance loopback filter. PR1157437
•
From Junos OS Release 13.2R1 and later, Packet Forwarding Engine interfaces on
Trio-based line cards might remain down after performing "request system reboot
both-routing-engines " or "restart chassisd" several times. Reboot the FPC might
restore it. PR1157987
•
RPD may crash after EVPN was configured when extra bits in the ESI label extended
community are set besides the single-active bit PR1158195
•
On MX Series platform, when MPC experiences a FATAL error, it gets reported to the
chassisd daemon. Based on the action that is defined for a FATAL error, the chassisd
will take subsequent action for the FATAL error. By default, the action for FATAL error
is to reset the MPC. When the MPC reports FATAL error, chassisd will send offline
message and will power off the MPC upon the ACK reception. However, if MPC is in
busy state for any reason, the ACK doesn't come in time and hence there would be a
delay in bringing down the MPC. The fix ensures to bring down the MPC in time upon
FATAL error. PR1159742
•
Software OS thread on the line card is doing a busy loop by reading the clock directly
from hardware, Sometimes it seems the thread is getting wrong values from HW
register and waiting forever in the busy loop. After the busy loop crosses a certain time
period, the line card crashes and reboots. This is a rare condition. PR1160452
•
The Router Lifetime field is set to 0 in the first Routing Advertisement sent from LNS
back to PPPoE subscriber. PR1160821
•
Upon receiving some specific packets, a compute CPU of the MS-MIC/MS-MPC will
stop refreshing the inactivity-timeout of sessions despite receiving traffic matching
them. As a result, an affected session will be removed when the inactivity-timeout
time has expired. PR1161040
Copyright © 2016, Juniper Networks, Inc.
141
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
The VCCPD_PROTOCOL_ADJDOWN system log message does not include a 'reason'
string to explain why the virtual chassis adjacency was terminated. This information
will now be present in the message. PR1161089
•
Default EVPN policy in junos-defaults for mx-series is removed. This was used to enable
per packet load-balance for EVPN routes. Now per-packet load balance needs to be
configured explicitly. PR1162433
•
Interfaces routing status message xxx.xxx.xxx.xxx <Up Broadcast Multicast Localup>
may be reported on an interface that is not associated with the config change, such
as bridge-domain addition. It should be reported only if there is any change in the IFL
parameters. This is an info(6) level message for debug purpose, so we can safely ignore
the cosmetic problem. rpd[xxx]: %DAEMON-6: EVENT Flags ge-1/0/4.0 index 371
10.180.230.8/24 -> 10.180.230.255 <Up Broadcast Multicast Localup> rpd[xxx]:
%DAEMON-6: EVENT Flags irb.110 index 326 10.9.17.254/22 -> 10.9.17.255 <Up
Broadcast Multicast Localup> rpd[xxx]: %DAEMON-6: EVENT Flags irb.190 index 373
10.9.53.254/22 -> 10.9.53.255 <Up Broadcast Multicast Localup> PR1162699
•
From Junos OS Release 14.1X51-D75, 15.1F4, and 15.2IB, if deactive interface, in rare
condition, due to a software defect, NH is getting deleted, while there are still routes
pointing to it, which leads to inconsistent states in Packet Forwarding Engine. The MPC
might crash or traffic blackhole. PR1164101
•
On MX Series router with MPC3/4/5/6/7E/8E/9E linecard, neither low-light warning
nor alarm work on these linecards with 10G or 100G interfaces. When using JAM image,
NG-MPC are affected as well. This is optics or fiber issue, no critical service impact.
PR1168589
142
•
When MS-MPC is used, if any bridging domain related configuration exists (e.g. "family
bridge", "“vlan-bridge"”, "“family evpn", etc), in some cases, continuous MS-MPC crash
hence traffic loss may occur. PR1169508
•
Adding keyword 'fast-filter-lookup' to existing filters of an input or output filter list may
result in failure to pass traffic. To avoid this issue, the filter list should first be deactivated
then the filters updated with a the keyword 'fast-filter-lookup; then the filter list
activated. PR1170286
•
If the "no-cell-share" configuration statement under the chassis stanza is activated
on MPC3, MPC4, MPC5, or MPC6 cards, the Packet Forwarding Engine will only be able
to forward about 62Gbps versus ~130Gbps and causing fabric queue drops. PR1170805
•
The fan speed logic does not operate correctly once PEM on MX104 platforms does
automatically shuts down due to over-temperature protection. The fan speed moves
back to speed normal. It takes more time for PEM to cool down and come back online
automatically with fan at normal speed. PR1174528
•
Storm control feature is not working on MX104 platform. In Packet Forwarding Engine,
associated filters and vty commands are not visible as well. It works on other MX Series
platforms. PR1176575
•
On dual Routing Engine system, if master Routing Engine is running Junos OS
13.3R9/14.1R7/14.2R5/15.1R3/15.2IB or later, backup Routing Engine is running Junos
OS prior to 13.3R9/14.1R7/14.2R5/15.1R3/15.2IB, a major alarm is raised. This is cosmetic
and can be safely ignored. Please upgrade backup Routing Engine to the same release
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
with master RE to avoid the issue. user@router> show system alarms 2 alarms currently
active Alarm time Class Description 2016-xx-xx xx:xx:xx UTC Major PEM 1 Not OK
2016-yy-yy yy:yy:yy UTC Major Host 1 failed to mount /var off HDD, emergency /var
created <<<<<<<<<<<<<<< PR1177571
•
In a rare error scenario krt_q_entry of flow route is freed without dequeuing it from the
queue. This has been fixed via software change. PR1178633
•
In EVPN A/S mode, IFL mark down programming at the Packet Forwarding Engine on
the BDF gets removed causing traffic loops. PR1179026
•
[EVPN] Active-Active IP4 L3 session with CE over IRB Flaps. PR1179105
•
On 10x10GE(LAN/WAN) SFPP PIC, when the port is configured with WAN PHY mode,
the CoS configuration on the port will be incorrectly programmed and it might result
in unexpected packet drop. PR1179556
•
In the CGNAT CLI show service alg conversations fails to display parent session status
for ALG conversations. PR1181140
•
When "dynamic-tunnels" is configured with configuration statement "gre", performing
Routing Engine switchover might result in rpd crash. PR1181986
•
If a bridge domain (BD) is created within an Ethernet VPN (EVPN) instance with type
of virtual-switch but its VLAN ID is not added to the extended vlan list, the BD works
in local switching mode only. When the BD's VLAN ID is then later added to the extended
vlan list, there might be a chance that the update is not properly replicated to the
routing protocol daemon (RPD) and therefore the EVPN database doesn't properly
learn local or remote MAC addresses. PR1182215
•
Fragmented ALG control traffic is not supported on the MS-MPC. PR1182910
•
With NAT translation-type as napt-44, a few sessions are getting stuck upon
deactivating/activating service-set or corresponding applications at a few times with
traffic running. The same symptom is seen upon deactivating/activating service-set
with traffic running and with 'deterministic-napt44' translation type as well. PR1183193
•
In EVPN environment, the rpd might crash when a bridge-domain within an EVPN
virtual-switch instance for VLAN X is deleted from the configuration when a trunk
interface which is part of the same instance still has VLAN X present in the vlan-id-list.
The core files can be seen via command "show system core-dumps" root@PE1> show
system core-dumps -rw-rw---- 1 root field 4974891 May 18 03:24
/var/tmp/rpd.core-tarball.0.tgz PR1183570
•
With BGP add-path and consistent-hash enabled, when a BGP learnt route prefix with
multiple paths(next-hop) is installed in the forwarding-table, all the next-hops should
be reachable/resolvable at the time of installing the route in the forwarding-table.
However, there might be a chance that any of the next-hops are not resolvable at that
time, which will lead Packet Forwarding Engine's incorrect route programming. In this
case, traffic forwarded to this prefix will be affected. PR1184504
•
When ams-interface is configured in warm-standby mode without adding any members,
configuration commit will lead to rdd core. PR1185702
Copyright © 2016, Juniper Networks, Inc.
143
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
AMS redundant interfaces not listed under possible-completions of operational
commands. PR1185710
•
ksyncd crash might be seen with GRES due to kernel replication error. PR1186317
•
The command "request system reboot both-routing-engines local' on VC-Mm will
reboot only one Routing Engine on an MX-VC, with this fix, it will reboot both Routing
Engines of local chassis. In addition, this fix also removes the "set virtual-chassis
member <n> role line-card" configuration option on an MX-VC because this option is
not supported on MX-VC as designed. PR1188383
•
In rare cases, a logical IRB interface (irb.x) might refer to a wrong MAC address when
sending unicast IPv6 neighbor solicitation (NS) (a packet type of IPv6 Neighbor
Discovery Protocol) to verify the reachability of a neighbor. The NS messages will with
a wrong source MAC address, result in the neighbor discard the packet and IPV6
neighborship goes to an unreachable state. Note: - Neighbor Solicitations are multicast
when the node (host or router) needs to resolve an address and unicast when the node
seeks to verify the reachability of a neighbor. For the first release of IRB supported
product, please refer to the following link:
https://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=2219
=Integrated+routing+and+bridging+(IRB) PR1191086
•
Memory leak in variable-sized malloc block leading to RPD crash due to "out of
memory". PR1198165
Class of Service (CoS)
•
When customers delete an IFL from an interface-set that has CoS applied to it and
activate CoS profile directly on that IFL in one single commit, commit fails with an error.
Commit goes through if they do it one by one, delete IFL from interface set, commit
and then activate CoS on that IFL, commit. PR1169272
Forwarding and Sampling
144
•
The configuration statement "interface-mac-limit" might be set to default value when
activating "mac-table-size" on a VPLS routing instance. Restarting l2ald, reapplying
the "interface-mac-limit" or changing to another value (set interface ge-3/1/0.0
interface-mac-limit 510) fixes the issue. user@router> show vpls statistics | match
count Current MAC count: 0 (Limit 1024) << set to default value 1024 instead of the
value set by interface-mac-limit PR1025503
•
On MX Series router with "network-services enhanced-ip" configuration. When firewall
daemon first come up as part of the system reboot, it could not read the chassis
network-service configuration statement from the kernel, which is expected. After so
many read retries, firewall daemon has to choose the default chassis network-service
IP mode. When the interface description change is committed, firewall reads the chassis
network-service configuration statement again. If it reads successfully, the firewall
daemon has to restart itself because the chassis network-service is enhanced-ip mode.
When firewall daemon is restarted, the openFlow connections get dropped. PR1035956
•
On MX Series routers, a change of policers or counters to an existing firewall filter using
physical-interface-filter or interface-specific configuration statements will not be
correctly detected by MIB2D. PR1157043
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Configuration container [protocols] [l2-learning] [global-mac-move] is made visible.
The functionality under it are already supported but the command was hidden till now.
PR1160708
•
After upgrading by using ISSU, as part of bring-up procedure, mib2d will initialize
connections to FPC Packet Forwarding Engines ( packet forwarding engines ). It might
start querying states from Packet Forwarding Engine while the connection is not ready
yet. This failure will cause the connection to reinitialize again. Thus this can form sort
of loop which can cause memory and CPU cycle usage to grow. As a result, it causes
mib2d to crash. PR1165136
•
Commit gives error as follows when apply-groups is configured under bridge domain.
error: Check-out failed for Firewall process (/usr/sbin/dfwd) without details. PR1166537
•
This issue will be seen only when there are huge number of routes having different BGP
NHs pointing to the same AS. Depending on the number of routes pointing to AS paths
and also the difference in BGP NHs in the routes can shoot up the srrd (Sampling
Route-Record Daemon) CPU consumption. In the real network this issue might not be
seen often, as the number of AS paths will be huge and the routes referring these AS
paths will be usually distributed among the AS paths. Even if the routes are pointing
to the same AS, the impact would be lesser than the one seen in this scenario.
PR1170656
•
When polling SNMP counters for Trio-Only firewall filters,
MIB2D_RTSLIB_READ_FAILURE cosmetic error messages might get reported in syslog.
PR1173057
•
statistics-service daemon (pfed) experiences constant memory leak of 10 KB every 2
minutes when MobileNext package is installed: > show version Model: mx480 Junos:
14.1X55-D30.10 JUNOS Base OS boot [14.1X55-D30.10] <...> JUNOS MobileNext Routing
Engine Software [14.1X55-D30.10] <<< this package PR1174193
•
Even if packets don't match firewall filter conditions, wildcard mask firewall filter might
match any packets. << Sample config >> ------------------------------------------------set firewall family inet filter TEST-filter term TEST1 from destination-address
0.0.0.255/0.0.0.255 <<<<<< set firewall family inet filter TEST-filter term TEST1 then
count TEST1 set firewall family inet filter TEST-filter term TEST1 then discard set
firewall family inet filter TEST-filter term TEST2 then accept
------------------------------------------------- This is discard filter for /24 prefix
broadcast address. However it might discard other packets. PR1175782
•
In EVPN/VXLAN environment, while Layer2 Address Learning Daemon (l2ald) is
processing MAC Routes during re-sync (whenever l2ald gets restarted) with kernel, if
MAC Route has stale information, it needs to be deleted by l2ald and then by the kernel.
Due to a software defect, there is no check for ifl validation, if ifl is invalid (which could
be due to several reasons such as config change), the l2ald process might crash, traffic
forwarding might be affected. PR1176177
•
SRRD(Sampling Route-Record Daemon) process doesn't delete routes when the
DELETE is received from RPD in few configuration cases. This results in build-up of
memory in SRRD daemon and once SRRD reaches the limit, it crashes and restarts
itself. This happens only when one certain family is not configured on all of the FPC
clients (e.g. FPC with inline jflow enabled or PIC with PIC-based sampling enabled is
Copyright © 2016, Juniper Networks, Inc.
145
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
one client). For example, only IPv4 family is configured in all the clients and, IPv6 and
MPLS families are not configured for sampling in any of the clients. PR1180158
•
FPC offline could trigger Sampling Route Record (SRRD) daemon restart. PR1191010
High Availability (HA) and Resiliency
•
The rtsock message length that was sent by ksyncd to kernel via rtsock was incorrectly
set to ipc length. PR1052425
•
Right after all FPC complete their upgrade, the kernel (on the VC-Mm) closes its
connection to ksyncd (on the VC-Bm) since it has received a message "invalid IPC type
20". This disconnect causes ksyncd to restart, it then cleans all kernel state in the
VC-Bm and starts the replication process. This causes the timer for waiting for the VC
to become GRES ready (after FPC upgrade) to expire and abort the ISSU. PR1163807
•
When configure the "nonstop-routing" under one group and apply this group to
routing-options configuration hierarchy, sometimes the NSR does not work. As a
workaround, please configure the "nonstop-routing" directly under the routing instance
hierarchy. PR1168818
Infrastructure
•
RPD stuck on high CPU utilization when executing 'show route multicast' CLI with
Invalid Option and RPD stops responding to any management requests. PR1027891
•
In scaling setup (in this case, there are 1000 VLANs, 1000 Bridge Domains, 120 IRB
interfaces, 120 VRRP instances, BGP and IGP), if the routing protocols are deactivated
and activated, there might be a chance that the pending route stats are not cleaned
up, which will cause the stats infra to have stale pointers and lead to memory corruption
in socket layers. The system might go to db prompt because of this. All the traffic going
through the router will be dropped. PR1146720
Interfaces and Chassis
146
•
In affected releases, the following cosmetic alarms are seen after reseating the clocking
cables: 2015-11-13 05:22:56 UTC Major CB 0 External-A LOS 2015-11-13 05:22:56 UTC
Major CB 0 External-B LOS PR1152035
•
SONET interface on MIC-3D-1OC192-XFP does not count input error correctly. While
hardware counts framing error, runts and giants but input error in 'show interface
extensive' command reports runts and giants only. PR1154268
•
When a Routing Engine (RE) experiences a media block error, the RE will try to switch
mastership immediately due to this software defect. The switch-over attempt happens
even on a single RE system which in this case will cause all FPCs to reset. PR1168494
•
If an interface configured with VRRP is removed from a routing-instance to global, or
from global to a routing-instance, the IFLs of that interface will be deleted and recreated.
In ideal cases as the interface gets deleted, VRRP should move to bringup state; when
the interface is created again, VRRP goes to previous state. After this, VRRP should
get VIP addition notification from kernel and update VRRP state and group id for VIP.
However, in race conditions, VRRP might get VIP addition notification from kernel even
before the interface creation event happens. If so, VRRP will never be able to update
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
proper VRRP state and group id. So the VIP will reply for the ARP with an incorrect
MAC ending with "00", while the correct MAC should end with the groups id configured.
PR1169808
•
In previous release, only IEEE classification is supported for CFM OAM packets. In the
fix, we will support 802.1AD based filter for CFM OAM packets. when Linktrace and
loopback requests are received in MX, 802.1p bits is used to determine the forwarding
class and queue for response or linktrace request forwarded to next router, this cause
these PDUs are put to wrong queue when input-vlan-map pop is present because
received PDU doesn't carry 802.1p bits. In the fix, we will use incoming forwarding class
to determine the 802.1p priority and outgoing forwarding class and queue for new
generated response or link trace requests. PR1175951
•
Commit check may exit without providing correct error message and causing dcd exit.
The only known scenario to trigger this issue is to configure a IPv6 host address with
any other address on the same family. PR1180426
•
when there is a configuration change, cfmd memory leak is observed and sometime
also may trigger cfmd coredump. Following messages are observed: /kernel: Process
(44128,cfmd) has exceeded 85% of RLIMIT_DATA: used 378212 KB Max 393216 KB
PR1186694
Junos Fusion Provider Edge
•
Do not issue commands that might generate more than 24k of output using the 'request
chassis satellite shell-command' command. Use 'request chassis satellite login' and
then run the commands in the resulting session. PR1188712
Layer 2 Features
•
In BGP-based VPLS scenarios, changing the configuration of a VPLS mesh group might
cause rpd core. FPC reboot might also be seen during the rpd core. PR1123155
•
From Junos OS Release 13.2R1 and later, the rpd process might crash when
adding/deleting Virtual private LAN service (VPLS) neighbors in a single commit. For
example, a primary neighbor is changed to become the backup neighbor. PR1151497
Multiprotocol Label Switching (MPLS)
•
In MPLS environment, the master Routing Engine might crash due to Mbuffer allocation
failure and this crash will trigger an Routing Engine switchover, as a result Backup
Routing Engine will become active. The issue is unreproducible, and trigger condition
is not clear. PR979448
•
Due to some data structure changes of ipc messages in 64-bit RPD, some of 32-bit
applications (e.g. lsping, lspmon) would not work normally when RPD is running in
64-bit mode. Depends on Junos version, some of cli commands might not work as
expected. PR1125266
•
User is allowed to configure both "load-balance-label-capability" and
"no-load-balance-label-capability" together. This is incorrect and confusing. PR1126439
•
Static MPLS LSP using VT interface as a outgoing interface would not come up.
PR1151737
Copyright © 2016, Juniper Networks, Inc.
147
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
With NSR enabled and LDP configured, the rpd process might crash and restart on the
new master Routing Engine after a Routing Engine switchover. PR1155002
•
LSPing returns 'routing instance does not exist' when used in vpls routing-instance
under logical system. PR1159588
•
If container LSP name and the suffix together are more than 60 characters in length,
rpd process might crash during extensive split merge conditions. Its always advisable
to keep them less than 60 characters. The member lsp name is coined in the following
manner: <container-name>-<suffix-name>-<member-count> The LSP name can
have upto 64 characters. So after putting together the container name, suffix,
member-count (could go up to 2 digits), and the 2 hyphens, it should not exceed 64.
So container-name and suffix together should not exceed 60 characters. A commit
check will be added to throw warning if the name is more than supported character
long. PR1160093
•
When L2VPN composite next hop configuration statement is enabled along with L2VPN
control-word, end-to-end communication fails. Because in this scenario, control-word
is not inserted by the ingress PE, but other end expects the control-word. PR1164584
•
Changing maximum-labels configuration under the hierarchy [edit interfaces
interface-name unit logical-unit-number family mpls] might cause existing MPLS LSPs
to become unusable. The root cause of this issue is that the family MPLS gets deleted
and re-added. PR1166470
•
In LDP-signaled VPLS environment, other vendor sends an Address Withdraw Message
with FEC TLV but without MAC list TLV. The LDP expected that Address Withdraw
Message with FEC TLV should always have MAC list TLV. As such, it rejected the
message and close the LDP session. The following message can be seen when this
issue occurs: A@lab> show log messages |match TLV RPD_LDP_SESSIONDOWN:
LDP session xxx.xxx.xxx.xxx is down, reason: received bad TLV PR1168849
•
In MVPN scenario, if active primary path goes down, then PLR(Point of Local Repair)
needs to send Label Withdraw for old path and new Label Mapping for new path to
the new upstream neighbor. In this case, LDP P2MP path may stay in "Inactive" state
for indefinite time if an LSR receives a Label Release, immediately followed by a Label
Mapping for the same P2MP LSP from the downstream neighbor. PR1170847
Network Management and Monitoring
148
•
In customer setup Packet Forwarding Engine was not able to keep-up with full stats
requests from PFED. Because of this delay, PFED runs out of transfer credits to send
stats request to Packet Forwarding Engine and starts returning full stats requests with
error response to mib2d with ifl-info flag set to LS STATS and a payload filled with
value zero. mib2d was treating the returned 0 filled stats value as correct stats and
was returning these 0 values. This results in spike in delta value calculated by the
customer side script. PR1010534
•
When syslog is forwarded to an external host, the millisecond and year format should
not be forwarded as it is a JUNOS specific implementation. When such details are
included in syslog messages sent to a remote host, it can result in duplicate timestamp
on log message as shown in following example. user@router> show log messages Oct
30 18:16:58.496 2014 MX96-1-re0 : %DAEMON-3: Oct 30 18:16:58.498 2014 MX96-1-re1
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
ffp[6375]: "dynamic-profiles": No change to profiles >>>>>>>>>>> Duplicate
timestamp PR1038616
Platform and Infrastructure
•
The mgd daemon (which manages the CLI) may crash when "system commit
persist-groups-inheritance" configuration statement is deleted and later added again.
PR1079991
•
Under large-scale setup, VPLS MAC might not be aged-out from remote-Packet
Forwarding Engine when local-Packet Forwarding Engine is
MPC3/MPC4/MPC3E/MPC4E, then unknown-unicast frames flood will be seen on
local Packet Forwarding Engine. PR1099253
•
When "system/commit/delta-export" is enabled, a system configuration commit may
result in crash and the following error. A core file might be generated. PR1102046
•
In certain cases, with some events such as disable/enable of links followed by Routing
Engine rebooting or GRES enabled switch-over, below error message could be seen
due to a software bug where it doesn't handle an internal flag properly. KERNEL/Packet
Forwarding Engine APP=NH OUT OF SYNC: error code 1 REASON: invalid NH add
received for an already existing nh ERROR-SPECIFIC INFO: PR1107170
•
Configuring one group with configuration of routing-instances and applying this group
under routing-instances, then the rpd process will crash after executing
"deactivating/activating routing-instances" commands. As a workaround, you can
avoid using "apply-groups" under routing-instances hierarchy. PR1109924
•
FPC can crash and core due to a missing NULL check. PR1144381
•
On MX2000 Series, MPC4 going offline is seen when SFB (Switch Fabric Board) is
offlined or removed. This could be caused by the build-up of CDR in ADC which leads
to transient packet loss or even getting stuck. The fix prevents line-cards going offline
due to transient buildup in ADC. PR1149677
•
With Enhanced LAG mode enabled and sampling configured on AE interfaces, MS-DPC
might drop all traffic as "regular discard". Disabling Enhanced LAG mode would avoid
this issue. PR1154394
•
On MX2000 series platform, when MPC goes down ungracefully, other MPCs in the
chassis will experience "destination timeout". In this situation, auto fabric-healing will
get triggered due to "destination timeout" condition, which may cause Fabric-Plane
reset, even all other MPCs to be restarted in some cases. PR1156069
•
cosd[20362]: cosd_config_database: Configuration
database(/var/run/db/juniper-prop.data) does not exist. cosd[20460]:
cosd_config_database: Configuration database(/var/run/db/juniper-prop.data) does
not exist. The above log messages may be seen after after some commits. These
messages do not pose an operational impact. PR1158127
•
If one logging user is a remote TACACS/RADIUS user, this remote user will be mapped
to a local user on device. For permissions authorization of flow-tap operations, when
they are set on the local device without setting the permissions on the remote server,
they cannot work correctly. The flow-tap operations are as follow: flow-tap -- Can
Copyright © 2016, Juniper Networks, Inc.
149
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
view flow-tap configuration flow-tap-control -- Can modify flow-tap configuration
flow-tap-operation -- Can tap flows PR1159832
150
•
LU(or XL) and XM chip based linecard might go to wedge condition after receiving
corrupted packets, and this might cause linecard rebooting. PR1160079
•
The MPC with LU chipset might crash after ISSU. PR1160748
•
Due to software bug on chassisd, backup CB temperature information is missing on
cli command 'show chassis environment cb' if it's replaced once. PR1163537
•
For MX Series Virtual Chassis with "default-address-selection" configured, when we
have a discard route to a specific subnet ( e.g., 10.0.0.0/8 ) with discard next-hop, and
at the same time we have more specific routes through other interfaces ( e.g., 10.1.1.1
through xe-0/0/0 ), if a UDP packet is being sent to 10.1.1.1 through xe-0/0/0 while
interface xe-0/0/0 flaps or FPC reboots, it might cause kernel crash on both Master
Routing Engine in the Virtual Chassis master router (VC-Mm) and Master Routing
Engine in Virtual Chassis backup router (VC-Bm). As a workaround, we can disable
"default-address-selection" configuration. PR1163706
•
The following log can be seen on MX2020 after one FPC was pulled out and committing
the configuration related interface: CHASSISD_UNSUPPORTED_FPC: FPC with I2C ID
of 0x0 is not supported. PR1164512
•
A sonet interface configured as unnumbered BFD session fails to come up. PR1165720
•
Modifying the configuration of a hierarchical policer when in use by more than 4000
subscribers on an FPC can cause the FPC to core and restart. PR1166123
•
Because the sequence number in RPM ICMP-PING probes is introduced as 32-bit
variable instead of 16-bit, if it increases and reaches the max value 65535, it does not
rollover, which might cause all RPM ICMP-PING probes to fail and not succeed any
more. PR1168874
•
In affected release, if user runs the Packet Forwarding Engine debug command like
"show sample-rr eg-table ipv4 entry ifl-index 1224 gateway 113.197.15.66" will cause
the MPC crash. PR1169370
•
Layer 2 protocols might flap when router was flooded with low priority traffic reaching
towards FPC CPU/Routing Engine CPU when DDoS protection is disabled. PR1172409
•
On MPC5E/6E/7E/8E/9E/NG linecards, firewall filter of family inet/inet6/vpls
configured with non-contiguous prefixes for address matching might fail and cause
traffic drop. Using only contiguous prefixes can avoid this issue. PR1172725
•
Because of an internal timer referring Time in Unix epoch (UNIX epoch January 1, 1970
00:00:00 UTC) value getting wrapped around for every 49 days, flows might get stuck
for more than the period of active/inactive time out period. The number of flows that
get stuck and how long they get stuck can not be deterministic exactly, which depends
on the number of flows at the time of timer wrapping around. PR1173710
•
"show arp" command can't get complete results and reports "error: could not find
interface entry for given index". PR1174150
•
A flow is determined by doing hashing on the packet header. Usually 5-tuple (src/dest
IP addresses, IP protocol number, src/dest ports) are used for hashing because a flow
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
is defined by 5-tuple. This is all fine for TCP/UDP packets. But Layer-3 packets
generated by JDSU tester only have Layer-3 header and don't have Layer-4 header.
JDSU tester uses the same location as Layer-4 header as packets' sequence number.
So MX Series card treats sequence number of JDSU tester packets as Layer-4 header
of a packet, hence Junos OS thinks every packet is a single flow and order of different
flows is not guaranteed. PR1177418
•
On MX2020/2010, chassisd file rotation on commit check will cause the trace file to
be stuck and no other operational chassisd events will be logged until chassisd restart.
PR1177625
Routing Protocols
•
Traffic drop from less than 400 ms to 8 seconds might be seen in RLFA scenario when
the primary link comes up. The reason for seeing the traffic drop is due to the delay in
ARP resolution on the new link that just came up and IGP has programmed that link
as the primary next hop. So though the FIB has been updated, Packet Forwarding
Engine cannot still use it as it waits for ARP resolution on the new link. PR1106310
•
BFD session configured with authentication of algorithm keyed-sha1 and keyed-md5
might be flapping occasionally due to FPC internal clock skew. PR1113744
•
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
•
On Junos-based products, changes in routing-instance, like changing route-distinguisher
or routing-option changes in some corner cases might lead to rpd crash. As a
workaround always deactivate routing-instance part that is to be changed before
committing the changes. PR1134511
•
When Protocol Independent Multicast (PIM) is used, in very rare condition, if the last
hop router (LHR) migrates from (Designated Router) DR to non-DR, repeated routing
protocol process (rpd) crash may occur due to patricia tree walk issue. PR1140230
•
In BGP scenario with large scale routing-instances and BGP peers configured, due to
a software defect (a long thread issue), BGP slow convergence might be seen. For
example, BGP might go down 8-9 seconds after BFD brings down the EBGP session.
The rpd slip usually does not hurt anything functionally, but if the slip gets big enough,
it could eventually cause tasks to not be done in time. For example, BGP keepalives
with lower than 90 seconds hold-time might be impacted. There is no known
workaround for this issue, but configuring the configuration statement "protocol bgp
precision-timers" can take care of the weak spot like sending BGP keepalives. PR1157655
•
In BGP scenario with independent domain enabled in a VRF, when configuring a BGP
session in a VRF routing instance with a wrong local-as number, some routes might
be declared as hidden because of AS path loop. If later configuring the correct AS
number as local-as and committing the configuration, those routes might still remain
in hidden state. The hidden routes can be released after performing the commands
"commit full" or "clear bgp table <ANY_VRF>.net.0". PR1165301
Copyright © 2016, Juniper Networks, Inc.
151
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In L3VPN scenario, feature multipath is configured under [set protocols bgp group]
with L3VPN chained CNH under routing-options, the feature multipath does not work
for L3VPN routes. PR1169289
•
When clearing IS-IS database, process rpd might crash due to a rare memory
de-allocation failure that a task pointer is attempted to be freed twice. In the fix of this
issue, the order of referencing the task pointer is being revised to avoid the occurrence
of rpd crash. PR1169903
•
PIM bootstrap export policy is not working as expected when there are no pim neighbors
up on the router PR1173607
•
In L3VPN scenario, VPN routes with different next-hops were advertised with same
label, leading to PE-CE link protection failure and longer than expected traffic loss (as
reported 2.6 sec). PR1182777
•
Any configuration change can cause deletion of a firewall filter created for a routing
instance if the flowspec routes in that instance are imported using rib-group, and there
is no "inet-vpn flow" address family configured and the routing instance does not have
any BGP group configured with "inet flow" address family. PR1185954
•
On the RSVP LSP scenario with ISIS configured, memory leak might happen in rpd and
Packet Forwarding Engine after the LSP re-optimization, and this migth cause FPC
crash. PR1187395
Services Applications
•
When making a configuration change to a EXP type rewrite-rule applied to a SONET
interface in an MX FPC Type 2 or MX FPC Type 3, if MS-DPC is also installed on the
device, a MS-PIC core dump may be generated. PR1137941
•
When NAT for SIP is enabled, in a rare situation where the child SIP flow entries are
still present in the parent conversation while they have already been deleted, the service
PIC might crash if the SIP parent flow tries to access them. PR1140496
•
On MX Series platform, when using MS-MPC, the "idpd_err.date" error message is filling
var/log. Please refer to KB30743 for details. PR1151945
•
When deleting NAT flow under a race condition the Service PIC can core. PR1159028
•
When traffic is flowing through MS-DPC card Service PIC and there is an active port
block and some ports are assigned from that active port block, if changing the
max-blocks-per-address setting to a lower value (lower than the current value), the
service line card may crash. PR1169314
•
MS-PIC core-dump when MPLS or IPV6 routing updates are received in the PIC.
PR1170869
•
When using MS-DPC under heavy load condition (e.g. with about 7m flows) with
deterministic NAT and port block allocation (PBA) scenario, in rare condition, MS-DPC
crash may occur due to memory issue. PR1186391
User Interface and Configuration
•
152
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
MGD spawns dexp with one of below three options: - delta-export is enabled in just
this commit, (so dexp.db should not exist) - Someone deactivated delta-export in
some previous commits and actiavted it now, so dexp.db in case if existing should be
discarded - For some reasons change bit is set on delta-export configuration statement
It is possible that an incorrect update into dexp.db goes through instead of just copying
the file, causing mismatch in config (i.e. we display config that was previously deleted
or miss some statements that have been applied). PR1168906
•
Description: Issue --------------- pinned-page found for bucket warning is seen after
application (in this case dfwc) is done with the page pool and trying to com eout after
ppool_close. Root-cause --------------- This warning is given when the application is
done with the page pool and tries to find out if there were any pinned pages in memory.
However this warning is basically internal to Junos development team and has been
masked in the later releases starting from 15.1 onwards with below: PR
https://gnats.juniper.net/web/default/1030715 Fix --------------- We have the taken
the relevant changes from PR 1030715 to prevent these flurry of warnings, and to enable
these warnings only for Junos development team upon enabling leak check internally.
PR1179264
VPNs
•
In NG-MVPN large-scale multicast routes (140k Rosen and 140k NGen MVPN routes
total in 500+ VRFs) network, RE switchover with GRES/NSR enabled, it might cause
multicast traffic loss . PR1086129
•
Upon clearing p2mp lsp in dual-home topology, system is adding the same outgoing
interface to the (S,G)OIL multiple times and thus duplicate/multiply the amount
outgoing traffic. PR1147947
Resolved Issues: 14.2R6
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 platforms, 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 can be avoided by applying
the "rate-limit and "buffer-size" on inserted MIC, then commit. PR1142182
Forwarding and Sampling
•
On MX80 and MX104 platforms, applying a firewall filter with an MX Series specific
match condition will raise the following warning message: "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 Series platforms since they can
have DPC and MPC mixed. But the message is not needed for MX80 and MX104
platforms since they only have the MX Series-based Packet Forwarding Engine. Although
the warning message indicates that the relevant firewall filter is not installed, the
firewall filter is correctly installed into the Packet Forwarding Engine. Thus, the user
can ignore the message in case it is logged on MX80 and MX104 platforms. PR1138220
Copyright © 2016, Juniper Networks, Inc.
153
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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, 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
•
The L2ald may crash after interface flap. PR1015297
•
On MX Series platforms, 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 issues). PR1037661
•
There is a remote loopback feature in 802.3ah standard, where one end can put the
remote end into remote-loopback mode by sending an enable loopback control LFM
PDU. In remote loopback, all incoming packets (except LFM packets) are sent back
on wire as it is. Transmit or receive of LFM packets should not be affected when an
interface is in remote loopback mode. On VMX platforms, when we configure the LFM
remote-loopback, we run into problem state. In problem state we will see that LFM
packets sent from node that 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 the peer router. PR1046423
•
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 adding 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 tells it to attach to
the policer, dfwd has already deleted the policer, and since rpd skipped re-adding it,
dfwd will reject the attach filter with a 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 route resolves over a direct route (e.g., a one-hop LSP), the
rpd process might crash. PR1063796
•
Link Up/Down SNMP traps for AE member links might not be generated, but the SNMP
traps for the AE bundle work well. PR1067011
•
PCE-initiated LSPs are less preferred than locally configured LSPs. After this issue is
fixed, PCE-initiated LSPs will have same preference as locally configured LSPs.
PR1075559
154
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
MPC connection to Routing Engine closed with below error logs: [May 19 19:41:23.724
LOG: Err] PQ3_IIC(WR): I/O error (i2c_stat=0xa3, i2c_ctl[1]=0xb0, bus_addr=0x77)
[May 19 19:41:23.724 LOG: Err] Failed to enable PCA9548(0x77):grp(0x1)->channel(1)
These logs are generated because the FPC ideeprom should not be accessed when
the card is online and cty to any FPC results in accessing the ideeprom of all the FPCs
in the Routing Engine, before establishing the actual cty. Routing Engine (cty) accessing
the ideeprom and the FPC accessing the I2c devices at the same point can result in
conflict and end up in port hang state and other issues. PR1089266
•
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 the kernel AE iffamily when subscribers log in/log out. PR1097824
•
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
•
With ECMP-FRR enabled, after rebooting the FPC which is hosting some ECMP links,
the ECMP-FRR might not work. Clearing any of BGP sessions (that are the part of
ECMP) could help to clear this issue. PR1101051
•
On MX Series platform, in rare condition, if Packet Forwarding Engine sends wrong
Packet Forwarding Engine id to chassisd as part of capability message, kernel might
crash and some FPCs might be stuck in the present state, the traffic forwarding will
be affected. This is a corner case, it is not reproduced consistently. PR1108532
•
On MX240/480/960 Series routers with MS-DPC, customers 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 multi-hop
BFD enabled. Traffic forwarding will not be affected. PR1109660
•
In rare condition, after Routing Engine switchover, the MPC PIC might offline, and some
error messages might be seen. At times chassisd on Routing Engine goes to continuous
coring makes unit unusable as none of interfaces come up. Root cause: After Routing
Engine switch over chassisd fail to get proper status of the FPCs and cores due to
insufficient IDEEPROM read times. PR1110590
•
Right now this fix is available from 14.2R6 and later. On 14.2R5 or earlier images, MSRPC
gates once opened would never get deleted. From 14.2R6 and later, MSRPC gates are
opened for 60 minutes no matter whether the expected packet hits the gate or not.
After 60 minutes, gates are deleted by the 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 platforms, when an LCC hit overtemp situation occurs, it might go offline
abruptly without notifing SFC and other LCCs, which might cause traffic loss or
Copyright © 2016, Juniper Networks, Inc.
155
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
performance degradation. Now with the fix, the overtemp situation on LCC is handled
gracefully. PR1116942
156
•
On M/MX Series platform, the 10G Tunable SFP/SFP+ cannot be tuned in Junos OS
Release 15.1R2. PR1117242
•
On MX Series routers containing multiple Packet Forwarding Engines such as
MX240/MX480/MX960/MX2010/MX2020, with MPC3E/MPC4E/MPC5E/MPC6E
cards, if the routers have GRE decap, then certain packet sizes coming via these line
cards at very high rate can cause these line cards to exhibit a lockup, and one or more
of their Packet Forwarding Engines corrupt traffic toward the router fabric. PR1117665
•
On MX Series platforms, in rare conditions, if removing or deactivating
"member-interfaces" configured for an aggregated Multiservices (AMS) bundle (only
officially supported on MS-MPC/MS-MIC), for example, using the 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, following 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 Series platforms, 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 check, for example, by the following CLI command, re# set interfaces ms-3/0/0
services-options ignore-errors tcp. PR1120079
•
Router is using BFD with its ECMP neighbours, when FPCs are rebooted, normally FPC
would resolve ARP one by one and update unilist and corresponding selector. But in
this case, due to a software defect, unilists remained stale and disabled. So the traffic
might be dropped or not be load balanced. PR1120809
•
On MX Series platforms, the MS-MPC crash might occur. The exact trigger of the issue
is unknown; normally, this issue might happen over long hours (e.g., within a week) of
traffic run (e.g., running HTTP/HTTPS/DNS/RTSP/TFP/FTP traffic profile). PR1124466
•
Right now this fix is available from Junos OS Release 14.2R6 and later. On Junos OS
Release 14.2R5 or earlier images, SUN RPC gates once opened would never get deleted.
From Junos OS Release 14.2R6 and later, SUN RPC gates are opened for 60 minutes
no matter whether the expected packet hits the gate or not. After 60 minutes, gates
are deleted by the timer. PR1125690
•
In an EVPN scenario, the EVPN route table between the master Routing Engine and
backup Routing Engine would be different (unused garbage routes will appear) once
Routing Engine switchover (e.g., by rebooting the "old" master Routing Engine or
performing a graceful Routing Engine switchover) is performed, which might cause a
kernel crash on the new master Routing Engine in some cases. PR1126195
•
When Junos OS devices use the Link Layer Discovery Protocol (LLDP) , the command
"show lldp neighbor" 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. A Junos OS CLI configuration statement can select which
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
"interface-name" or "SNMP ifIndex" to generate for the PortID TLV, so we do not have
any problem as long as two Junos OS devices are connected for LLDP, but we might
have an interoperability issue if another vendor’s device that can map the configured
'port description' in the PortID TLV is used. In this case, Junos OS displays the neighbor's
PortDescription TLV in the Port info field, and if the peer sets the port description whose
TLV length is longer than 33 bytes (included), Junos OS is not able to accept the LLDP
packets and discards the 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
•
If two redundant logical tunnel (rlt) sub-interfaces are configured in the same subnet
and in the same routing-instance, a sub-interface will be down (this is expected), but
if the sub-interface is removed from the routing-instance later, after disabling and
enabling the rlt interface, a sub-interface might remain in the down state unless you
remove the configuration of the rlt interface and then do a rollback. PR1127200
•
In current Juniper Networks implementation, the IPv6 multicast Router Advertisement
timer is not a 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 Series routers with MS-MIC (or possibly, MS-MPC is affected as well), changing
the 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
(ALGs) on MS-MPC/MS-MIC, if running a 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 MX Series-based line card, multiple modifications of the firewall filter might cause
lookup chip error and traffic blackhole. The 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 the 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
Copyright © 2016, Juniper Networks, Inc.
157
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
should convey the same message to the user. The changes have been made to make
sure CLI and XML information given to the user is in sync. PR1132006
•
When customers do changes under "protocol router-advertisement interface X" (such
as changing timers, etc.), they expect that a commit would trigger a new
router-advertisement being sent out to notify hosts about configuration changes.
However, this does not seem to be the case, unfortunately. It makes the router
information to expire on hosts and causes obvious loss of connectivity for the hosts.
PR1132345
158
•
In a situation where both mirrored interface and mirrored destination are on MPC card
and mirror destination interface is a unilist next-hop (e.g., an ae interface), mirrored
packets may get dropped. PR1134523
•
On MX Series platforms 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" are configured for
services. PR1137596
•
On MX Series platforms, the "Max Power Consumption" of MPC Type 1 3D (model
number: MX-MPC1-3D) would exceed the default value due to software issues. For
example, the value might be shown as 368 Watts instead of 239 Watts when "max
ambient temperature" is 55 degrees Celsius. PR1137925
•
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
•
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
•
On 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
•
With a 100G CFP2 MIC installed in a MPC6E FPC, if the FPC fails to initialize the MIC,
it is very likely that the FPC will get into boot loop. PR1148325
•
In EVPN environments, when CE MAC address alone gets changed for a MAC+IP entry,
the new MAC+IP entry is not getting reflected in the EVPN database and the old entry
still exists on the PE router. PR1149340
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Commit error after attempting to delete all guaranteed rates on all
traffic-control-profiles associated with demux0 [edit] lab@mx480-J12_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 platforms, traffic going 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, there is no other
service impact. PR1152254
•
Routers using inline Layer 2 services may experience Packet Forwarding Engine wedge
leading to fabric degradation and FPC restart. During issue state, the affected FPC will
not be able to transmit and traffic will be fully blackholed. This problem is amplified
by fragmented and out of order packets. This log entry may 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 the command "user@router> show chassis
environment", their status is Absent, but no alarms. This is a minor issue, it does not
affect business. PR1156841
•
On Junos devices with a GRE or IPIP tunnel configured (i.e., devices with a gr- or ipinterface), a specifically crafted ICMP packet can cause a kernel panic resulting in a
denial of service condition. Knowledge of network specific information is required to
craft such an ICMP packet. Receipt of such a packet on any interface on the device
can cause a crash. Refer to JSA10752 for more information. PR1159454
•
On MX Series routers with enhanced queuing DPCs, there is a memory leak whenever
doing SNMP walk to any of COS related OIDs or issue the command "show interfaces
interface-set queue <interface-set-name>". PR1160642
High Availability (HA) and Resiliency
•
With NSR enabled on multiple Routing Engine systems, when a dynamic GRE tunnel
is configured, performing Routing Engine switchover might cause rpd to crash repeatedly
on backup the Routing Engine. 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
•
On M/T/PTX platforms, the SNMP requests may return timeout if SNMP pollings on
IF-MIB and COS-MIB for the same ifl/ifd are requested at the same time. This is a
generic async stats infra issue in kernel. On MX Series platforms, the same issue may
not be seen since SNMP pollings for ifl stats go through pfed instead of kernel on MX
Series platforms. PR1149389
Copyright © 2016, Juniper Networks, Inc.
159
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 Series 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 Series virtual chassis provides another MIB,
jnxVirtualChassisMemberTable, to supply the equivalent "top-level" information.
PR1024660
160
•
MS-DPC might crash when allocating chain-composite next hop in an enhanced LAG
scenario. PR1058699
•
The following CLI configuration statement needs to be used for the CFM session to
work: "set chassis aggregated-devices disable-lag-enhanced." Enhanced-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
•
MXVC-specific behavior for SNMP walk of jnxOperating* containers was divergent
from the physical MX Series. 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, cannot handle scaling 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 keepalive messages will also
not get memory. PR1136702
•
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), the client needs to exchange keepalive 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 the following 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 might 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 the L2VPN interface if it is configured after
L2VPN is up. PR1145001
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Starting from 12.3R4, on dual-RE equipped M series routers, due to the mismatch of
online status of the missing FRU (e.g., FPC or FEB which is not inserted, but is reported
as online on backup Control Board), error messages about the missing FRU might be
seen intermittently on the device. 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 vendor'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. Depending on topology, there might be a loop and causing
broadcast storm. PR1158444
•
When a Routing Engine (RE) experiences a media block error, the RE will try to switch
mastership immediately due to this software defect. The switch-over attempt happens
even on a single RE system which in this case will cause all FPCs to reset. PR1168494
J-Web
•
An information leak vulnerability in J-Web may allow unauthenticated remote users
with network access to the J-Web service to gain administrative privileges or perform
certain administrative actions on the device. Refer to JSA10754 for more information.
PR1114274
Junos Fusion Provider Edge
•
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
•
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
Layer 2 Features
•
In VRRP scenario, one host connected to active and backup VRRP switches, if the host
send huge amount of traffic continuously to backup VRRP switch, it might cause high
ppmd (Periodic Packet Management Daemon) CPU utilization and slow response on
backup VRRP switch. PR1124038
•
In VPLS scenario with AE interfaces as core facing interfaces, when LDP mesh-group
is enabled with local-switching enabled in it, the neighbors configured under the
local-switching hierarchical will cause LSI (Label-Switched Interface) to be created
automatically. If port flapping occurs causing MPLS interface change associated with
the LSI interface, the VPLS split-horizon might not be in functionality, this will cause
traffic to be looped back. As a workaround, configuring configuration statement
"enhanced-ip" can avoid this issue. PR1138842
•
In a VPLS scenario, when "$junos-underlying-interface-unit" is configured in the
"dynamic-profiles" hierarchy, which is then implemented in a routing-instance,
upgrade/commit will fail with the following error message: Parse of the dynamic profile
Copyright © 2016, Juniper Networks, Inc.
161
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
(<dynamic_profile_name>) for the interface: $junos-interface-ifd-name and unit:
$junos-underlying-interface-unit failed. PR1147990
•
For routers equipped with the following line cards: T4000-FPC5-3D, MX-MPC3E-3D,
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 Routing
Engine switchover. PR1116741
•
For Routing Engine generated packet with VLAN tag, if the outgoing interface is an LT
interface, the VLAN tag will not be removed even if 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 has failed, the Power Supply failed alarm is generated every 30
minutes. The expected interval is every 60 minutes. This is a minor issue, there is no
other service impact. PR1144795
•
The "Node ID" information is not shown on MX Series platform when traceoption flag
"pdu" is configured to trace Ethernet ring protection switching (ERPS) PDU reception
and transmission. PR1157219
Multiprotocol Label Switching (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 points to the indirect composite next
hop in kernel, but the composite next hop can be deleted in rpd even when the egress
protection route is pointing to the composite next hop. This results in composite next
hop "File exists" error when the egress protection is re-enabled and reuses the
composite next hop (new CNH addition fails as old CNH is still referenced in kernel).
PR954154
•
162
Please see CVBC section PR1054491
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
In MPLS scenarios, removing the "family mpls" configuration from an outgoing interface
may cause inet and/or inet6 next hops associated with that interface to unexpectedly
transit to dead state. Even adding back "family mpls" cannot restore it. PR1067915
•
For advertising IPV6 packets over an MPLS GRE tunnel, the IPv6 address gets stuck in
the KRT queue. PR1113967
•
If a RSVP LSP has both primary and secondary 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
•
During interoperation with Cisco device (e.g., CRS) belonging to different IGP area, if
the P2MP LSP ping echo reply message from the Cisco device is using interface address
other than loopback/router-id as the source address, the reply message will be dropped
on the Junos OS device. With the fix, the Junos OS 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 a session_preemted
PathErr message to the upstream node without sending a ResvTear message. Hence
the ingress node does not receive the 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 timed out and it
sends a ResvTear message to the ingress. PR1140177
•
There is no entropy label for an LDP route in the scenario of LDP tunneling across a
single-hop RSVP LSP with label 0 (explicit-null) used. As a workaround, either remove
LDP tunneling or RSVP explicit-null will resolve the issue. PR1142357
•
This issue is related to inter-op between a multivendor scenario. This fix will add
sub-object RRO, which will help change of label during an 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
•
In LDP P2MP scenario with NSR, after performing multiple iterations of FPC reloads,
protocol bounce, interface bounce, GRES, rpd restarts in random, in rare condition, the
rpd process might crash, the routing protocols are impacted and traffic disruption will
be seen due to loss of routing information. PR1148404
Copyright © 2016, Juniper Networks, Inc.
163
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
With NSR enabled and LDP configured, the rpd process might crash and restart on the
new master Routing Engine after a Routing Engine switchover. PR1155002
•
If container LSP name and the suffix together are more than 60 characters in length,
rpd process might crash during extensive split merge conditions. Its always advisable
to keep them less than 60 characters. The member lsp name is coined in the following
manner: <container-name>-<suffix-name>-<member-count>. The LSP name can
have upto 64 characters. So after putting together the container name, suffix,
member-count (could go up to 2 digits), and the 2 hyphens, it should not exceed 64.
So container-name and suffix together should not exceed 60 characters. A commit
check will be added to throw warning if the name is more than supported character
long. PR1160093
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 the source address of and
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 the SNMP trap source.
PR1153722
Platform and Infrastructure
164
•
When one of the "deny-commands" is incorrectly defined in the profile of a TACACS+
server, all "deny-commands" regexes will be ignored, which leads to an over-permissive
profile without any warning. PR1078238
•
Fragmenting a special host outbound IP packet with an invalid IP header length (IP
header length is greater than actual memory buffer packet header length) can trigger
NULL mbuf accessing and dereferencing, which might lead to a kernel panic. PR1102044
•
Junos OS defines the 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 an AE interface,
the packets which cross VCP links might be dropped on the egress VCP Packet
Forwarding Engine due to an invalid fabric token. PR1112752
•
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
extended period, the Flexible PIC Concentrator (FPC) might run out of memory and
stop operating. PR1114369
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Inline 6rd and 6to4 support for XL and XL-XM-based platforms. PR1116924
•
In certain specific network/operating system configurations when a telnet or SSH
session client is initiated from a Junos OS device to another device, both the telnet/SSH
server, and the telnet/SSH client incorrectly handle the TCP connection on each end.
In this event, both the client and the server are stuck in various TCP states and never
establish the connection, or release the connection. PR1123496
•
On MX Series-based line cards, for GRE over IPv6 packet with layer 4 length less than
8 bytes, it will be discard with reason "L4 len too short". PR1126752
•
On MX Series platforms, 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 Packet Forwarding Engine) faults. This fault is non-fatal and would not cause
service impact. The line cards that may hit the issue could be seen as: 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
•
On MX Series based line card platform, if FPC offline is performed while FPC is in online
progress (online process is at the stage of fabric links training), in very corner scenario,
the Routing Engines state is stale and being sent to other existing FPCs, so the traffic
forwarding might be affected. PR1130440
•
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 the 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 13 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 Packet Forwarding Engine for
TCP control connection with Routing Engine. This could cause: 1. MX-VC DDoS
protection violation for VC-control low queue and makds MXVC split. 2. Routing Engine
and FPC high CPU utilization. PR1133293
•
With scaled firewall filters attached to interfaces (e.g., 10k+ filters), running the "show
configuration" command can cause high CPU of the mgd process. As a workaround,
use the "show configuration | display set" command to view the config. PR1134117
•
On XM chip-based line cards (e.g., MPC3/4/5/6, and FPC type 5), in rare situations,
when LU or XL chip congestion occurs (e.g., may occur when configuring with more
than 4000 entries in the multicast list and large traffic performing replication, please
note this is not a realistic configuration), XM chip wedge may occur. PR1136973
Copyright © 2016, Juniper Networks, Inc.
165
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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 behavior. For Zone 1 (PSM 9 to 17), FAN 3 shows the above behavior. PR1138209
•
When the CLI command "show Packet Forwarding Engine statistics exceptions | match
reject" is executed, the CPROD thread in the Packet Forwarding Engine may hog the
CPU and result in an FPC crash. PR1142823
•
Receipt of a specifically crafted UDP packet destined to an interface IP address of a
Junos OS device with a 64-bit architecture may result in a kernel crash. This issue only
affects systems with a 64-bit architecture. 32-bit systems are unaffected by this
vulnerability. Refer to JSA10758 for more information. PR1142939
•
When ARP is trying to receive a next hop 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
•
In certain affected Junos OS Releases, executing the "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
•
On MX Series platform with MX Series based line card, inline 6rd with si interface is
deployed, if downlink traffic is over ECMP or AE, some traffic might be dropped.
PR1149280
•
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 Packet Forwarding Engines.
PR1149840
166
•
When the NTP server address is configured in a routing instance 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 of the configured source-address. As a result, the NTP server
cannot send the NTP packet back. PR1150005
•
FPC may experience blackhole of traffic after lmem data error in private zone. PR1152026
•
During an ISSU upgrade in MXVC environment, linecards may crash, causing service
impact. When the linecards come up, there may be a nexthop programming issue as
a secondary impact and some IFLs may not pass traffic. Affected linecards 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 to crash and the MS-MPC/MS-MIC to
keep crashing. As a workaround, configure RPM to perform timestamping either on the
Routing Engine (Routing Engine-based RPM) or on an installed MPC Packet Forwarding
Engine (Inline-RPM). PR1152785
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Fixed an issue with Inline J-Flow 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
•
The logs CHASSISD_READBACK_ERROR are reported on the backup Routing Engine
for the non-empty FPCs. PR1155823
•
Configuring a firewall filter with multiple terms matching either on flexible-match-mask
or flexible-match-range might lead to FPC crashing while trying to program the firewall
filter and add it to the local table. PR1157759
•
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
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 to a non-existent/inactive routing-instance will be permitted.
If we have a conditional policy referring to 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 to active routing-instances. PR1144766
Routing Protocols
•
If the command to trace ppm is issued from the FPC shell and a malformed incoming
packet (required to be handled by PPM) is in the buffer, the FPC may crash. An example
of such a malformed packet would be a multihop BFD packet with an incorrect length
(larger than normal). PR1082878
•
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
•
After executing the CLI commands "show route detail" or "show route extensive," the
routing protocol process (RPD) might get stuck in an infinite loop and might stop
responding to any events such as CLI commands, protocol keepalives, etc. This would
result in a timeout 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 that is
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
•
Triggered S,G,RPT join is not being sent immediately upon receiving the *,G join or S,G
join on RPT tree. Join to S,G,RPT will go over periodic join result in delay pulling traffic
till the periodic join sent. PR1107896
Copyright © 2016, Juniper Networks, Inc.
167
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
168
•
This issue is a regression defect introduced in Junos OS Release 11.4R11, 12.1R10, 12.2R8,
12.3R6, 13.2R4, 13.3R2, and 14.1R1. After upgrading to those releases containing the
original fix, when there is no export policy configured for the forwarding table to select
a specific LSP, whenever routes are resolved over RSVP (for example, due to aggressive
auto-bandwidth), the resolver will spend a considerable amount of time on the resolver
tree, which contributes to a baseline increase in rpd/Routing Engine CPU. PR1110854
•
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 will crash. PR1113319
•
On a dual Routing Engine router, BFD is configured for BGP with holddown-interval.
After a BFD flap (disabling/enabling the interface) the BGP/BFD is up in master Routing
Engine, but in backup Routing Engine still shows BGP/BFD down, it will never come
up. PR1115429
•
There may be a stale BFD session after channging physical in terface MTU, it may also
cause BFD session flap to be 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 ares 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 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 ensure 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
•
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 is exhausted, the rpd process might crash, and the routing
protocols are impacted and traffic disruption will be seen due to loss of routing
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
information. You can check rpd memory usage with the "show task memory brief"
command. PR1124923
•
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 an 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 gets deleted on the router (e.g., receives the (S,G)
prune from the downstream PIM router), the router will incorrectly stop forwarding the
multicast traffic even if a rendezvous-point tree (RPT) path exists. PR1130279
•
On dual Routing Engine platforms, due to a software issue, the OSPF (including both
OSPFv2 and OSPFv3) the "DoNotAge" bit (e.g., source of LSA has flood-reduction
feature enabled) is not mirrored to the backup routing protocol process (rpd). In this
situation, after performing nonstop active routing (NSR) switchover, the LSA on the
new master rpd remains without the "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 causes backup Routing Engine core. The
exact root cause is not known. While processing updates on the backup Routing Engine
(received from master Routing Engine), accessing free pointer causes the core.
PR1135701
•
On dual Routing Engine platform with Bidirectional Forwarding Detection (BFD) protocol
enabled, after graceful Routing Engine switchover (GRES), the periodic packet
management process (ppmd) might crash on the backup Routing Engine due to a
software defect. PR1138582
•
Deleting mvpn configuration from routing instance "delete routing-instances
<instance-name> protocols mvpn" might cause routing daemon on master RE to
crash. PR1141265
•
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 bytes for IPv4 and 12 bytes 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
•
With NSR configured, when the BFD sessions are replicated on the backup Routing
Engine, the master will not send the source address, instead the backup Routing Engine
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, the
new master will have this all-zeros source address. When a 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
Copyright © 2016, Juniper Networks, Inc.
169
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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 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
generated by rpd (next-hop events in the current case) and messages get delivered
in an 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 issue. PR1153932
•
OpenSSH client software supports an undocumented feature called roaming: if the
connection to an SSH server breaks unexpectedly, and if the server supports roaming
as well, the client is able to reconnect to the server and resume the suspended SSH
session. This functionality contains two vulnerabilities that can be exploited by a
malicious SSH server (or a trusted but compromised server): an information leak
(memory disclosure), and a buffer overflow (heap-based). Refer to
http://kb.juniper.net/JSA10734 for more information. PR1154016
•
BGP Monitoring Protocol (BMP) feature is introduced in 13.3R1. When BMP is configured
in passive mode and BMP session is closed ungracefully (e.g. No TCP FIN sent), in rare
cases, the TCP session might not be cleaned up properly and rpd process crash might
be observed during the re-establishment of the previous session. PR1154017
•
When rib-group copy is done for a route change, the rib-group copy of the secondary
route into the destination tables of the copy may not honor maximum-prefixes in some
scenarios, such as upon damping changes. The traffic forwarding might be affected.
PR1157842
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
170
•
When committing a configuration with a 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 on the system. As a workaround, please configure
as-path to be less than 4096 characters long. PR1119529
•
When there are two or more sessions accessing the router, and one of the sessions
(for example, session 1) is executing commit check in configuration private mode, if
another session (for example, session 2) is keeping executing commit-and-quit in
configuration private mode, because the commit check is not keeping the lock on the
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
local Routing Engine for the entire session, there is a chance that session 2 will hit a
Database opening error. The detailed sequence events are as follows: (1) Session 1:
commit check is not keeping the lock on local Routing Engine for entire session, once
commit check on local is a success, while it asked for lock on other Routing Engine. (2)
Session 2: mgd acquired db lock on local Routing Engine. (3) Session 1: once commit
check is completed on remote Routing Engine, it does cleanup and deletes the
juniper.data+ (created by Session 2). (4) Session 2: juniper.data+ is still in use at local
Routing Engine by daemons and daemons start complaining about it and emit the
messages as "Database open failed for file '/var/run/db/juniper.data+' ". PR1141576
VPNs
•
On dual Routing Engine platforms 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
the backup Routing Engine as following: Master rpd follows the below sequences
(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 environments (10k L2VPN) where the router has multiple BGP
peers, and different L2VPN routing-instances are deleted and added back. PR1104723
•
In L2circuit environments, 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 get stuck in "RD" state on
the remote PE. PR1125438
Resolved Issues: 14.2R5
Class of Service (CoS)
•
On MX104 platforms, 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 platforms, 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
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 a child link in the
existing AE in the “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
Copyright © 2016, Juniper Networks, Inc.
171
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
This issue is seen in Junos OS Release 14.2 and later. 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
•
This issue might be seen if following conditions are met: * AE sub-interface with firewall
filters * FPC reboot or new FPC is coming up * shared-bandwidth-policer or regular
policers (not a must - but easier to hit) If at the time of FPC restarting if a timing
condition presents itself whereby the filter for that sub-interface isn't received, this
can cause FPC to panic and crash. PR1113915
•
On MX Series platform with MX-FPC/DPC, M7/10i with Enhance-FEB, M120, M320 with
E3-FPC, when there are large-sized IPv6 firewall filters(for example, use prefix lists
with 64k prefixes each) enabled, commit/commit check would fail and dfwd process
would crash after configuration commit/commit check. There is no operational impact.
PR1120633
•
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 the 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 the Routing Engine kernel). In this situation, the FPC would
crash due to this rare timing issue. This issue might be avoided by the following
recommended steps: 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. Reactivate
interface. PR1128518
General Routing
172
•
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 the default instance no such issue is
observed. PR972603
•
On MX Series platforms, when an aggregated Ethernet bundle participating as an
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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
messages would be transient in nature. The discrepancy of next-hop handling that is
addressed in this PR can also manifest itself in form of other issues in the system.
Basically when the next hops 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
•
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
•
It is observed that the syslog messages related to kernel and Packet Forwarding Engine
may get generated at an excessive rate, especially in a 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
•
PR1060070
•
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
•
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 the Fabric path side is affected, the
Copyright © 2016, Juniper Networks, Inc.
173
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
fabric healing process will initiate this process automatically to recover from such
conditions. Corrupted parcels from Lookup chip LU/XL to Center Chip (XM) can also
compromise packet forwarding and report DRD parcel timeout errors. An additional
parcel verification check is added to prevent sending corrupted parcels to the center
chip (XM) PR1067234
•
CFP2-100GBASE-ER4 is supported on MIC6-100G-CFP2/MPC6E/MPC5E from
13.3R8/14.1R6/14.2R3-S4/14.2R4-S1/14.2R5/15.1R2/15.2R1 PR1069112
•
On MX Series platforms 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 paths are
blocked, the service PIC goes down and does not come up. PR1079745
•
FPC/MIC usually performs i2c bus transactions to detect presence/absence of SFPs.
When it fails to read SFP EEPROM due to i2c bus timing related and/or i2c bus hang
issues, the FPC crashes with the interfaces flap. The i2c bus should be held up in bad
state because faulty EEPROM SFP or non Juniper qualified SFP might be used.
PR1080566
174
•
The Scheduler: Protect: Parity error for tick table single messages might appear in
MPC3E/MPC4E/MPC5E/MPC6E/T4000-FPC5. PR1083959
•
The MIB counter or "show Packet Forwarding Engine statistics traffic" shows junk PPS
and invalid total traffic output counter. PR1084515
•
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 taking ms-mic offline with IPsec and J-Flow configured
on same ms-mic with dynamic IPsec tunnels. PR1086819
•
On MX Series routers with MPCs/MICs, if a rlsq interface is receiving continuous
fragmented traffic, doing rlsq switchovers a couple of times might cause the 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,
which is caused by split events (i.e., loss of all adjacencies by link failure, FPC restarts,
chassis power-down, Routing Engine reboots, etc.), then once the VCP adjacency is
formed again, the current design could not determine the 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
•
Scuba MPC6E Temperature Intake shows as "Testing" in "show chassis environment",
but "show chassis environment fpc" and "show chassis fpc detail" are OK and provide
the correct Temp information. > show chassis hardware | match fpc FPC 0 REV 66
750-044130 ABDA3551 MPC6E 3D FPC 9 REV 31 750-031087 CADR7177 MPC Type 1
3D FPC 10 REV 66 750-044130 ABCZ2741 MPC6E 3D {master} > show chassis
environment | match "intake |state" | match fpc FPC 0 Intake Testing <<<<<<<<
Wrong info FPC 9 Intake OK 37 degrees C / 98 degrees F FPC 10 Intake Testing
<<<<<<<< Wrong info {master} > show chassis environment fpc | match
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
"fpc|intake|state" FPC 0 status: State Online <<<<<<<<<<<<<<<<<< Correct info
Temperature Intake 36 degrees C / 96 degrees F FPC 9 status: State Online
Temperature Intake 37 degrees C / 98 degrees F FPC 10 status: State Online
<<<<<<<<<<<<<<<<<< Correct info Temperature Intake 42 degrees C / 107 degrees
F {master} > show chassis fpc detail Slot 0 information: State Online Temperature 36
<<<<<<<<<<<<<< Correct info Total CPU DRAM 3584 MB Total XR2 518 MB Total
DDR DRAM 49920 MB Start time: 2015-05-12 12:36:14 AST Uptime: 9 days, 1 hour, 31
minutes, 38 seconds Max Power Consumption 1088 Watts Slot 9 information: State
Online Temperature 37 Total CPU DRAM 2048 MB Total RLDRAM 331 MB Total DDR
DRAM 1280 MB Start time: 2015-05-12 12:38:00 AST Uptime: 9 days, 1 hour, 29 minutes,
52 seconds Max Power Consumption 239 Watts Slot 10 information: State Online
Temperature 42 <<<<<<<<<<<<<< Correct info Total CPU DRAM 3584 MB Total
XR2 518 MB Total DDR DRAM 49920 MB Start time: 2015-05-12 12:36:18 AST Uptime:
9 days, 1 hour, 31 minutes, 34 seconds Max Power Consumption 1088 Watts PR1090671
•
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".
user@device> 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>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, the rpd
process is determining the Routing Engine mastership mode too early before chassisd
is determining the mastership , which would cause overload feature not to work properly.
PR1096073
•
Continuous error messages are seen after adding/deleting ae child link. MIC: unknown
option 132, ifd 305/xe-4/0/11, cmic_eth_boolean_set IFFPC: 'IFD Ether boolean set'
(opcode 55) failed ifd 305; Ether boolean set error (7) There is no known service impact
due to these messages. PR1097262
•
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. These
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
Copyright © 2016, Juniper Networks, Inc.
175
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
& 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
•
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
•
On Trio-based platform, 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
•
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, and the
clock source might be ineligible due to "Interface unit missing" or "Unsupported
interface" with no Ethernet Synchronization Message Channel (ESMC) transmit
interfaces. PR1098902
•
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
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 bringing down the interface on the best path, the
local repair will be triggered by the BFD session down but it might fail due to a timing
issue. This will cause slow converge and unexpected traffic drop. PR1098961
•
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 because 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
176
•
On MX Series-based platform, before creating a new unilist next hop, 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 a lower reference watermark for available
resource, thereby ensuring that it can allocate resource. PR1099753
•
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
•
In abnormal session close scenario like by pulling-out running ms-mpc or in scaled
flow environments, some garbage object can remain due to a bug on internal flow
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
state machine then would trigger mspmand coredump. The fix of this PR clears such
a problematic status objects. PR1100363
•
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 scenarios (for example, more than 100K routes). As a workaround,
execute the command "set pfe ipclog filter clear" to disable IPC logging on all FPCs.
PR1100851
•
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 a 6PE scenario, if
the system is not using LSI/vt, then it is not susceptible. If processed via MPC line card
will be affected, the MPC line card will crash. If processed via the MPC line card will be
affected, and the MPC line card will crash. If processed via endpoint receiving, the MPC
line card terminating tunneling protocols such as MPLS/IPSec VPNs, etc., will be
affected; this is considered an 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 following link:
http://kb.juniper.net/InfoCenter/index?page=content=JSA10701=SIRT_1=LISTPR1102581
•
On a QFX3500 switch with nonstop active routing (NSR) enabled, deleting a
routing-instance or logical-system configuration might cause a soft assert of the rpd
process. If NSR is not enabled, after you delete a routing-instance or logical-system
configuration, executing "restart routing" might trigger this issue, too. This issue has
no functional impact. PR1102767
•
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
•
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. Ifthere 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
•
When mspmand (which manages the Multiservice PIC) core dump (when the mspmand
crash, it will dump a core file for analysis) is in progress in MS-MPC/MS-MIC and a
GRES command is issued at the same time, it is seen that the MS PIC gets stuck and
has to be recovered by offlining/onlining the PIC. PR1105773
•
On MPC-3D-16XGE-SFPP line cards, when an optics (for example, 10G-LR-SFP) is
disabled and then enabled administratively, if the SFP is not temperature tolerant
Copyright © 2016, Juniper Networks, Inc.
177
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
(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
•
When bridge domain in PBB-EVPN routing instance is modified to add/remove ISIDs,
bridge domain 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 an IPv6 VRRP scenario, when a host sends router solicitation messages to a
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
•
On MX Series platforms, 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 follows: - 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
178
•
Due to a software defect found in 13.3R7.3 and 14.1R5.4 inclusively, Juniper Networks
strongly discourage the use of Junos software version 13.3R7.3 on routers with MQ-based
MPC. This includes MX-Series with MPC1, MPC2; all mid-range MX-Series; and some
of EX9200 line cards. PR1108826
•
On MX Series routers , when using FTP Application-level gateway (ALG), if the FTP
(including both active mode and passive mode) server requests client to use different
IP address for control session and data session (i.e. after the control session is
established, the destination IP address of FTP server is changed on which client should
transfer the data), although the control session could be built, the data session could
not be established due to wrong pinhole creation. The issue would not occur in the
scenario that the port is changed while the destination IP address is the same. PR1111542
•
In the scenario that the power gets removed from the MS-MPC, but Routing Engine is
still online (for example, on MX960 platforms 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 switching off the PEM that supports the MS-MPC situated slot), if the
power goes back on(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 an 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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
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 can be avoided by preventing the tunnel
destination of a tunnel to be learned through a second tunnel (and the other way
round). PR1113754
•
On ACX Series routers with Junos OS Release 12.3X54-D20 or 12.3X54-D25, 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
•
On MX-VC with a heartbeat connection, if it is in a scaled subscribers environment,
when powering down both VCM Routing Engines, there might be a delay (minutes) for
the 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
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,
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
•
The rpd process might crash when executing the CLI command "show evpn database"
with the combination of "vlan-id" and "mac-address". PR1119301
•
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 conditions, backup Kernel will not be able to see them. So after Routing
Engine switchover, the new master Kernel will delete the next-hop ID for such routes,
but Packet Forwarding Engines will not see this deleted message. As a result, the
Kernel/Packet Forwarding Engine are out of sync for such particular next-hop ID, and
might trigger a reset of all the Packet Forwarding Engines. As a workaround, do the
Routing Engine switchover in more than 30 minutes intervals. PR1119836
Copyright © 2016, Juniper Networks, Inc.
179
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On MS-MPC equipped MX Series platforms, 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 check. For example, by CLI command below, re# set interfaces ms-3/0/0
services-options ignore-errors tcp. PR1120079
•
Router is using BFD with its ECMP neighbours, when FPCs are rebooted, normally FPC
would resolve ARP one by one and update unilist and corresponding selector. But in
this case, due to a software defect, unilists remained stale and disabled. So the traffic
might be dropped or not be load balanced. PR1120809
•
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 recommended option: [edit system services static-subscribers
group PROFILE-STATIC_INTERFACE] + interface demux0.10001001 upto
demux0.10003000; PR1121876
•
ovs-vxlan -- irb mac address is missing in ovs data base PR1122826
•
In multihoming EVPN scenarios 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
•
In an EVPN scenario, the EVPN route table between the master Routing Engine and
backup Routing Engine would be different (unused garbage routes will appear) once
Routing Engine switchover (e.g, by rebooting the "old" master Routing Engine or
performing a graceful Routing Engine switchover) is performed, which might cause a
kernel crash on the new master Routing Engine in some cases. PR1126195
•
On MX Series platform, agentd daemon causes high disk (e.g. SSD) Input/Output
activity (e.g. about 25MB/s I/O activity) due to new feature of SDN-telemetry (as
known as agentd) added in Junos OS Release 14.2 onward and fabric statistics sensor
is per default enabled updating the Database every 2 seconds. As more FPCs are
installed in the system as higher the database record update rate. The CLI command
"set system processes SDN-Telemetry disable" is not working and could not be used
to disable the process. PR1130475
•
In the PPP environment, when a subscriber is logged out, its IFL index is freed, but in
rare conditions 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, the developer just adds
some debug information. PR1057610
•
In dynamic subscriber management scenario, when we executing CLI command "show
subscribers physical-interface <interface_name> count" from the master Routing
Engine, the active and total subscriber counts might be always shown as zero. As a
workaround, we can execute this command from the backup Routing Engine.
PR1096348
•
180
FFP is a generic process that will be called during the commit process, and FFP calls
the PDB initialization as part of its process. On the PDB-unsupported platforms (MX
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Series, M10i, M120, M320 is PDB-supported), when committing configuration, some
error messages will be seen. PR1103035
•
Log sdb_free_snapshot_handle: trying to free an already freed snapshot appearing in
messages log after upgrade to 13.3R7. This message was intended to be a trace message
but was mistakenly written to the messages log. There is no impact associated with
this log message. PR1116795
High Availability (HA) and Resiliency
•
On dual Routing Engine platforms 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 the 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 Routing Engine
due to keepalives timeout. PR1078255
•
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
Infrastructure
•
When the "show version detail" CLI command has been executed, it will call a separate
gstatd process with parameter "-vvX". Because the gstatd could not recognize these
parameters, it will run once without any parameter then exit. In the results of "show
version detail", the following information could be seen: user@hostA> 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-initializing 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 platforms, 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.
181
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Interfaces and Chassis
•
dcd will crash if targeted-distribution is applied to ge ifd via dynamic-profile. PR1054145
•
For Junos OS Release 13.3R1 or 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 being offline.
PR1060764
182
•
Currently the redundant logical tunnel (rlt) interface only supports limited vlan range
(0..1023), it should support the extended vlan range (0..4094) as the logical tunnel
does. PR1085565
•
On T4000/TXP-3D platform with HCFPCs (FPC Type-5) as source FPCs, if there are
multiple online/offline/restart of FRUs(FPC/Sib) happening together, for example, at
system boot time/GRES time/SPMB reboot time, the FM (Fabric Manager) will process
these events sequentially and be busy. If one destination FPC flaps at this time, all
HCFPCs might drop traffic to this FPC. PR1087798
•
Trap messages are not logged on logical interface (ifl) after deleting the "no-traps"
configuration statement, in spite of setting explicit "traps". PR1087913
•
In anMX 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 (5
min) 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 go down; the
expected 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 environments, 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 follows: .. 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 ae interfaces disappear
in MX-VC. It seemed that ae interfaces are not allocated a MAC address from chassisd
properly. * This issue only happens first configuration timing after rebooting/restarting
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
chassisd. So even if you configure related ae interface config repeatedly, you cannot
find this issue. When this issue happens, these messages will be found in messages
logs: ------------------------------------------------- lab@router_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 a
workaround. Deactivate/activate ae interfaces. (We need to do this to all disappeared
ae interfaces.) PR1100731
•
VRRP inet6 group interface does not send Router Advertisement (RA) when the
interface address and virtual address are same. run show ipv6 router-advertisement
interface ge-0/2/0.430 Interface: ge-0/2/0.430 Advertisements sent: 0 Solicits
received: 0 Advertisements received: 0 PR1101685
•
Because of the error injection rate configured by the user on a Routing Engine via the
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
•
The 'optics' option will now display data for VCP ports: show interfaces diagnostics
optics vcp-0/0/0. PR1106105
•
On MX240 or MX480 platforms with at least two DC modules (PN: 740-027736)
equipped, when shutting down one of the PEMs and then turning 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 all Junos OS Series 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 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 follows: user@re0> show system storage | match " /var$"
/dev/ad2s1f 34G 18G 13G 57% /var <Indicate that "/var" is mounted from the HDD/SSD
user@re0>show system storage | match " /var$" <<<No output here, it means that
the Routing Engine is running from "emergency /var">PR1112580
•
Junos OS Series now checks ifl information under the ae interface and prints only if it
is part of it PR1114110
•
Sometimes IQ2 PIC connection with kernel may drop after FEB redundancy switchover
under N:1 scenario, which will cause packets to drop on this PIC. PR1120097
•
When using Ethernet OAM Connectivity Fault Management (CFM), the CFM process
(CFMD) may crash in either of the following scenarios, - Scenario 1 When CFMD is
Copyright © 2016, Juniper Networks, Inc.
183
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
restarted or GRES. There is no specific defined configuration which could cause this
crash, but normally this would be seen with VPLS or Bridge domain with multiple
Mesh-groups. The crash happens rarely in this scenario. - Scenario 2 When configuring
2 interfaces in the same bridge-domain (BD) or routing-instance, and both interfaces
have maintenance association end point (MEP) configuration along with action-profile
enabled. Also there is no maintenance association intermediate point (MIP)
configuration on that BD or routing-instance. The crash might be seen with the above
configurations and when one of the interfaces is flapped or deleted and then re-created.
In addition, in this scenario, this issue may not happen always as this depends on the
ordering of kernel event. PR1120387
•
On Junos OS platforms, an aggregateEthernet 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 is seen when LFM is enabled on the aggregateEthernet
bundle. The issue is triggered when one of the member link flaps. Although after the
flap, the current master Routing Engine will show correct aggregate speed, the backup
Routing Engine will report an incorrect value. In this state, when Routing Engine
mastership is switched, the new master Routing Engine (which was backup) will show
a value. One of the side effects of this issue is that RSVP also reflects incorrect
bandwidth availability for the affected aggregateEthernet bundle, this can cause
under-utilization of the link with LSP having bandwidth constraints. PR1121631
•
Since a bug which was introduced in Junos OS Release 15.1R1, loopback sub-interfaces
always have a Flag down in the output of the CLI command "show interfaces".
PR1123618
•
The connectivity fault management (CFM) log message "Adjacency up" should only
be logged when the router first detects a remote MEP or the peer interface goes down
and up causing adjacency failure for this remote MEP. Now it is wrongly logged when
any peer sets/clears the Remote defect indication (RDI) bit in continuity check
messages (CCMs). PR1125164
•
With incomplete cfmd configuration, for example, only MD (maintenance-domain)
configured and no MA (maintenance-association) configured, or MD and MA configured
but no MEP configured, SNMP walk in CFM MD table results in infinite loop and process
cfmd is spinning at around 90% CPU. PR1129652
J-Web
•
Junos: Multiple vulnerabilities in J-Web (CVE-2016-1261); Refer to
https://kb.juniper.net/JSA10723 for more information. PR1082543
•
Junos: Multiple vulnerabilities in J-Web (CVE-2016-1261); Refer to
https://kb.juniper.net/JSA10723 for more information. PR1085428
Junos Fusion Provider Edge
184
•
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
•
When configuring "chassis satellite-management" for the first time on the aggregation
device (AD) in a Junos Fusion environment, one of the initialization steps by the satellite
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
discovery and provisioning daemon (sdpd) may not complete due to a timing issue.
This will affect software upgrade and conversion of satellite devices. To recover from
this state, restart the sdpd daemon using the CLI command “restart
satellite-discovery-provision-process”. PR1131762
•
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
Layer 2 Features
•
If equipped with both MPC/MSDPC and other type of DPCs, for local switching at mesh
group level, split horizon on PW interfaces won't work and could cause packets to loop
back to the same PW interface. PR1084130
•
In MX Series Virtual Chassis (MXVC) environments, 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, which 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 a different
member (for example, VC member 0), it will send the frame to member 0 via the vcpintf. If xe-4/0/1.670 belongs to an AE bundle which has multiple child links, a hash
needs to be run on the 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 the 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 the status of "Negotiated PW status TLV" of VPLS
connection is "NO", and the BGP-based VPLS connection cannot up even the L2circuit
is up due to the fact that check of neighbor state may incorrectly based on the presence
of the configuration statement. PR1108208
Layer 2 Ethernet Services
•
With scaled subscribers connected, restarting one of MPCs might cause subscribers
to be unable to log in for about 2 mins. PR1099237
•
V44 defines the next generation of Juniper Fabric using MX Series 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. The aggregated Ethernet (ae)
bundle over v44 extended ports does not come up. PR1101266
•
On MX Series platforms 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, execute the CLI command "clear dhcp server
binding <address>" to restore. PR1118421
Copyright © 2016, Juniper Networks, Inc.
185
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
For PVSTP/VSTP protocols, when an MX Series router inter-operates with a Cisco
device, due to the incompatible BPDU format (there are additional 8 bytes after the
required PVID TLV in the BPDU for the Cisco device), the MX Series might drop these
BPDUs. PR1120688
•
In a scenario where DHCP relay is used along with Virtual Extensible Local Area Network
(VXLAN), if a DHCP discover packet is received with the broadcast bit set via a VXLAN
interface on the 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
Multiprotocol Label Switching (MPLS)
186
•
In Resource Reservation Protocol (RSVP) environments, 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 and 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 (for example, 1.5 seconds)
to function and the traffic loss might be seen in 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
•
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 get
stuck in bypass LSP forever. This is a timing issue. PR1091774
•
If LDP is enabled via the 'protocols ldp' configuration option on a device running Junos
OS, receipt of a spoofed, crafted LDP packet may cause the RPD routing process to
crash and restart. Refer to JSA10715 for more information. PR1096835
•
On dual Routing Engine platforms with GRES, the kernel synchronization process
(ksyncd) may crash on the backup Routing Engine when adding a route pointing to
indirect next hop on the system. PR1102724
•
In Junos OS Release 13.2R1 and later, in an MPLS L3VPN scenario, when the
"l3vpn-composite-nexthop" configuration statement 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,
disable "l3vpn-composite-nexthop". PR1109948
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
If "optimize-timer" is configured under P2MP branch LSP, this branch LSP will not be
re-established if the link flaps on egress node. If "optimize-timer" is configured at the
protocols/mpls level, this 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 go down. PR1115004
•
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 headers and then drop these packets as "L3
incompletes" in the output of "show interface extensive". PR1117064
•
When multipoint LDP (M-LDP) in-band signaling is enabled to carry multicast traffic
across an existing IP/MPLS backbone and routing process is enabled to use 64-bit
mode, the rpd might crash due to accessing uninitialized local variables. PR1118459
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 cause Net-SNMP errors, "Received bad msgID".
PR1123832
•
In 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 MX Series-based line cards, 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 the 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 configuration
statement "groups re0 interfaces fxp0 unit 0" is configured. If you disable interface
fxp0, the backup Routing Engine is unable to proceed with commit processing due to
SIGHUP not received, the rpd process on the backup Routing Engine might crash.
PR974430
•
Junos: Multiple vulnerabilities in cURL and libcurl; Refer to
https://kb.juniper.net/JSA10743 for more information. PR1068204
•
On Trio based platform, when delete/deactivate configuration of AE interfaces, FPC
might crash due to de-referencing a NULL logical interface pointer. PR1069411
•
Junos: Manipulating TCP timestamps can lead to resource exhaustion denial of service
(CVE-2016-1269); Refer to https://kb.juniper.net/JSA10736 for more information.
PR1073571
Copyright © 2016, Juniper Networks, Inc.
187
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
188
•
On MX Series-based platforms, when learning the MAC address from the pseudo-IFL
(for example, label-switched interface), if the MAC address is aged out in the source
FPC where the MAC got learned, 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 might be deleted first from the egress Packet
Forwarding Engine but get added again during these 2-3 millisecond time intervals.
(As there is continuous traffic coming on the egress FPC destined to this MAC, the MAC
query is generated and sent to the Routing Engine and source FPC. Since the source
FPC has not yet processed the MAC-deleted message, it sends the response, so stale
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
•
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 the rpf neighbor between the master Routing
Engine and the slave Routing Engine. PR1087795
•
Issue is specific to 64bbit 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: Replace the wildcard with actual routing-instance name as in this 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 routers, 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 the Routing Engine, the VID 0 will not be imposed, causing the frames to get
dropped at the Routing Engine. PR1090718
•
When a P2MP LSP is added or deleted at ingress LSR, traffic loss is seen to the existing
sub-LSP(s) at the 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" configuration 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. This feature
is broken from Junos Release 14.1R1 when "enhanced-ip" is configured on MX Series
platforms with pure MPCs/MICsbased line cards. The bandwidth/burst-size of policers
attached to aggregated Ethernet interfaces are not dynamically updated upon member
link flaps. PR1098486
•
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
system or routing instance. Therefore, packets might be unexpectedly discarded,
leading to session/mastership flaps. PR1099608
•
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 packets 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 50 ms. If FPC restarts, some BFD sessions might flap.
PR1102116
•
On an MPC3E or MPC4E or on an EX9200-2C-8XS line cards, when the flow-detection
feature is enabled under the [edit system ddos-protection] hierarchy, if suspicious
control flows are received, two issues might occur on the device. Issue 1: Sometimes,
the suspicious control flow might not be detected on the MPC or line cards. Issue 2:
Once the suspicious control flows are detected, they might never time out even if traffic
flows no longer violate control parameters. PR1102997
•
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 equipped with FPC Type-5 , 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 (20 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 additions/deletions. Rebooting MPC
in a controlled maintenance window is the only way to restore memory. PR1105644
•
When "shared-bandwidth-policer" is configured with aggregate Ethernet (AE) and
has more than one member link on the same Packet Forwarding Engine and the policer
is configured with the "physical-interface-policer" configuration 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 filter with a policer is referenced by multiple IFLs of the same interface (A),
with traffic coming into that interface A and going out from another interface B,
whenever the policer is updated (for example, deactivating and activating interface
A. Or adding/deleting AE legs when A is an AE interface and shared-bandwidth-policer
is configured), it might be seen that there is counter statistics for the counter which is
placed in the ingress direction of interface C, even though interface C is an unrelated
interface which is not in the traffic path. Also FPC core dump and FPC going offline
might be seen. PR1106887
•
When a common scheduler is shared by multiple scheduler maps which apply to
different VLANs of an aggregated Ethernet (AE) interface, if the configuration statement
Copyright © 2016, Juniper Networks, Inc.
189
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
"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
•
CVE-2015-5477 A vulnerability in ISC BIND's handling of queries for TKEY records may
allow remote attackers to terminate the daemon process on an assertion failure. See
http://kb.juniper.net/JSA10718. PR1108761
•
DHCP End options (option 255) is missing by DHCP-relay agent (where 20 bytes DHCP
options 82 inserted) for client DHCP discover message with 19 bytes 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
•
When inline BFD sessions and inline J-Flow 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 being dropped.
PR1116886
•
When inline static NAT translation is used, if two rules defined in two service sets are
pointing to the same source-prefix or destination-prefix, changing the prefix of one of
the rule and then rolling back the changes is not changing back all the pools correctly.
PR1117197
190
•
On Junos OS-based line cards 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 a Routing Engine (RE) 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 (RE) 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 OS 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
(RE) to crash. Reboot the backup Routing Engine to restore. PR1122057
•
On Junos OS-based line cards with MPCs/MICs, for GRE over IPv6 packet with layer 4
length less than 8 bytes, it will be discarded by reason "L4 len too short". PR1126752
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
On MX Series platform, when fragmented packets go through the inline NAT (including
source NAT, destination NAT, and twice NAT), the TCP/UDP checksum would not be
correctly updated. In this situation, checksum error would occur on the remote end
(inside and outside device). Non-fragmented packets would not be affected by the
issue. If possible, this issue could be avoided by either of the following workarounds,
* Enable "ignore-TCP/UDP-Checksum errors" at the inside or outside device which
processes TCP/UDP data OR * Make sure there will not be any fragments subjected
to inline NAT functionality by appropriate MTU adjustment or setting PR1128671
•
Parity error at ucode location which has instruction init_xtxn_fields_drop_or_clip will
lead to a LU Wedge. LU is lookup ASIC inside the Trio. The LU wedge will cause the
fabric self ping to fail which will lead to a FPC reset. This is a transient HW fault, which
will be repaired after the FPC reset. There is no RMA needed unless the same location
continues to fail multiple times. PR1129500
•
On Junos OS devices running with DHCP Relay configuration 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
Routing Policy and Firewall Filters
•
On M7i/M10i with enhanced CFEB, M320 with E3-FPC, M120, and MX Series with DPC,
when the flood filter is configured in a 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
•
Support for the Pragmatic General Multicast protocol (daemon pgmd) is being phased
out from Junos. In Junos OS Release 14.2, the CLI is now hidden (although the
component is still there and configurable). In Junos OS 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 committing a new configuration. As a
workaround, remove all the unused VRF and VPLS instances. PR1006689
•
In Junos OS Release 14.1R1 or later, the rpd process might crash while executing CLI
command "show isis backup spf results". PR1037114
•
During NSR switchover, inline BFD transmit entries might take long time to replicate
to backup RE and BFD may flap. PR1063303
•
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
Copyright © 2016, Juniper Networks, Inc.
191
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
There are two issues in the PR: (1) In multicast environments, 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
•
If the command to trace ppm is issued from the FPC shell and a malformed incoming
packet (required to be handled by PPM) is in the buffer, the FPC may crash. An example
of such a malformed packet would be a multihop BFD packet with an incorrect length
(larger than normal). PR1082878
•
On large-scale BGP RIB, the advertised-prefixes counter might show the wrong value
due to a timing issue. PR1084125
•
In BGP environments, 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 the CLI
command "commit full" to make configuration changes. PR1093317
•
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
192
•
Due to software bug, Junos OS cannot purge so called doppelganger LSP, if such LSP
is received over a 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 is removed, the ISIS LSDB contents get 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, a
routing protocol process (rpd) crash occurs. PR1103631
•
A vulnerability in OpenSSH may allow a remote network-based attacker to effectively
bypass restrictions on the number of authentication attempts, as defined by
MaxAuthTries settings on Junos OS. 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 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.
Refer to JSA10697 (http://kb.juniper.net/JSA10697) for more information. PR1106752
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 a logical unit of 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 to the missing check for logical interface
(IFL) index change. 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 the master Routing Engine with
reason "CHASSISD_ISSU_ERROR: Daemon ISSU Abort -1(NSR sync not complete:
MSDP)". PR1129003
•
Deleting mvpn configuration from routing instance "delete routing-instances
<instance-name> protocols mvpn" might cause routing daemon on master Routing
Engine to crash. PR1141265
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) is 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, 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 through a SIP Routing Engine-Invite message.
PR1112307
Copyright © 2016, Juniper Networks, Inc.
193
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In a CGNAT environment, when a service PIC is in heavy load continuously, there might
be a thread yielding loop in CPUs, which will cause the CPU utilization to be high, and
might cause one of the CPUs to be reset. PR1115277
•
In a 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 was deleted due to timer
expiry, the PIC crashed whenever the code tried to delete the same flow again.
PR1116800
Software Installation and Upgrade
•
Add the "on <host> " argument to to "request system software validate" to allow
validation on a remote host/Routing Engine running Junos OS. 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 it is 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 logging out subscribers. PR1094674
•
In subscriber management environment, the authentication process (authd) crash
may occur. This issue is not reproduced yet, possibly, it might be seen when generating
a CLI Change of Authorization (CoA) request (e.g. via CLI command "request
network-access aaa subscriber add service-profile filter-service session-id 10"), then
logging out the subscriber (the one with service just activated), if the management CLI
session is closed before subscriber entry is reused, the crash may occur. 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 is dropped though it is not in the shortest-path tree (SPT) path from source to
receiver. PR1087948
•
In scenario involving pseudowire redundancy where the CE facing interface in the
backup neighbor (can be non-standby, standby, or 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 a down state.
PR1101886
194
•
In an L2VPN or VPLS scenario with Junos OS 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 a Global Table Multicast (GTM, internet multicast) instance, the ingress PE
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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
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)
•
In SNMP environments, when performing multiple walks or parallel snmpget for the
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 timed out when FPC is responding the request, a 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 the 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 interfaces 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 the cosd process and this lead to a memory hold in cosd. PR1071349
•
On MX Series platforms, when an 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 the 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 an unified in-service software updgrade from Release
13.2R8.2 to 13.3R7.3 results in the following messages seen in the syslog:
cosd_remove_ae_ifl_from_snmp_db ae40.0 error 2. These messages appear to be
harmless with no functionality impact. PR1093090
•
When performing the RE switchover without GRES enabled, due to the fact that the
Class-of-Service process (cosd) may fail to delete the traffic control 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 a 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. 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
Copyright © 2016, Juniper Networks, Inc.
195
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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
•
In PTX Series Carrier-Grade Service Engine (CSE) jflow solution environment, because
the sampling process (sampled) may get into a continuous loop when handling
asynchronous event (for example, aggregated tethered services interface flapping, or
route update, or IFL/IFD update), the sampled may never come out of that loop which
may result in high CPU usage (up to 90 % sometimes). Because, sampled is not able
to consume any states (such as route updates, interface updates) generated by kernel
and this results in memory exhaustion, finally resulting in the router not making any
updates and forcing a router reboot. PR1092684
General Routing
196
•
Changing the static route configuration from next-hop to qualified-next-hop might
result in static route getting missed from the routing table. Restarting routing process
can bring back the routes but with the rpd will crash. PR827727
•
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 a 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 the 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
•
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. This causes 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 connection failure
logs are seen. PR1003714
•
On MPC5, MPC6, MIC6-10G, and MIC6-100G line cards, in order to increase the resiliency
of the system, changes have been made to monitor board voltage levels and ASIC
currents periodically against the expected values, and update current threshold values
as per updated values provided by HW group. PR1004431
•
Link flapping might cause data traffic corruption. On T-series platform running Junos
OS 12.3R7, 13.1R4, 13.2R4-S1, 13.2R5, 13.3R2, 14.1R1, and later release and with
FPC1/2/3/4-ES linecard installed, in rare cases, link flapping might lead to "IP - Pkt
Len Mismatch error" followed by FPC reboot. PR1013522
•
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 platforms, when trying to view the Network Address Translation (NAT)
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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 50 ms), the "hold-time down"
may fail to keep the interface in "up" state within the configured time period. PR1032272
•
On a Virtual Chassis topology with SNMP enabled, the system might not send an SNMP
traps (jnxVccpPortUp/jnxVccpPortDown) when the VCP up/down events occurring.
PR1033723
•
In an 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 is 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 that are not supported on MX-VC in Junos OS Release
14.2R3. PR1034420
•
FX sfp is supported on 20x1Ge -E/-EH mics in this release. PR1038923
•
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 with a subsequent delete
and create of LSQ interface (not always though) - 14.1R4.10. PR1044340
•
The following message is generated every 5 second in MX104 on 14.2R1~R3 and 15.1R1.
xxx chassisd[1362]: Cannot read hw.chassis.startup_time: No such file or directory ..
PR1049015
•
On all Junos based platforms, there are two different types of memory blocks that
might be leaked. The first issue is rpd-trace memory block leak. There is one block each
for any trace files opened for rpd. They could be leaked for each time a configuration
commit is done. Around 40 bytes are leaked per operation. The issue does not occur
in Junos OS Release prior to 14.1. The second issue is rt_parse_memory block leak which
could happen during the configuration of aggregate routes, configuration information
might not be freed. Around 16384 bytes are leaked per operation. This issue is a day-1
issue. PR1052614
•
As a precautionary measure, a periodic sanity check is added to the 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 unified
in-service software upgrade (ISSU). The interrupt might have been prevented after
performing unified ISSU due to disabling the interrupt registers before unified ISSU,
but never restored after. PR1059098
Copyright © 2016, Juniper Networks, Inc.
197
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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, the
aggregate next-hop referred by that route will have the child unicast next hop pointing
to the .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
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 next hop
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
issues. 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 the receiving packets on a GRE tunnel, NAT was
dropping all protocols other than PPTP on the GRE tunnel. PR1069872
•
On MX Series routers with MPC based line cards in a setup involving Packet Forwarding
Engine fast reroute (FRR) applications, when a 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 the following 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 exist. 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 this is a non-impacting issue.
PR1071408
198
•
The dfwd process might crash when kernel messages for objects such as IFL or IFF are
sent to the dfwd process soon after its dynamic profile delete request. This is a race
condition. PR1074068
•
For Network Address Translation (NAT), Traffic Detection Function (TDF), or IPsec
service configured on MX Series platforms with MS-MPC/MS-MIC, the received
fragmented IPv4/IPv6 packets will be re-assembled and sent out. Under a 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 the 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 than 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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Vendor provided the fix, which includes conditional check PR1076369
•
On MX Series router, 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 (RE).
Optimization is done through this fix to handle the situation gracefully so that high CPU
will not occur. PR1077976
•
Starting from Junos OS Release 14.1R1, if the hidden configuration statement "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 an incorrect destination MAC. PR1079219
•
In a subscriber management environment, the PPP daemon (jpppd) might crash
repeatedly due to a memory double-free issue. PR1079511
•
On MX Series platforms 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 line card and recover those errors first. PR1081771
•
MPC is showing the below log messages and will generate core as the logic for clearing
references to JNH memory pools that have been discarded did not handle those in Bulk
DMEM. jnh_private_mem_pool_free(898): No private mem_pool for
0x00300000/00100000 PR1081855
•
When a MX Series 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
•
In multi-homing and signal active EVPN scenario, if IRB interface is included in the
instance, when the DF-CE link flaps, due to a timing issue, the DF might send L3 EVPN
routes with label 0 to remote PEs, causing traffic to be dropped at remote PE.
PR1082287
•
“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
•
On PTX platform, the FPC may crash when the interface goes down (e.g. disabling the
interface or interface flap occurs) due to failure during CNH NH change (composite
next hop, e.g. created in P2MP LSP scenario). Based on the current observation, the
probability of the issue might be low. PR1082429
Copyright © 2016, Juniper Networks, Inc.
199
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
200
•
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 the 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
OID's 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 the MX Series router acting
as BC, it might happen that the 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 taking ms-mic offline with IPsec and J-Flow 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
•
In the specific configuration of an 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
•
In the dual Routing Engines scenario with GRES and ae0 interfaces configured, if GRES
is disabled on the system, the backup Routing Engine should remove the ae0 bundle.
However, it does not and ae0 remains in the backup Routing Engine. After switching
Routing Engine mastership to make the other Routing Engine as master, the new master
Routing Engine (which was backup earlier) continues to use the invalid MAC address
"00:00:00:00:00:00". PR1089946
•
On PTX platforms, some non-fatal interrupts (for example, CM cache or AQD interrupts)
are logged as fatal interrupts. The following log messages will be shown on CM parity
interrupt: fpc0 TQCHIP 0: CM parity Fatal interrupt,Interrupt status:0x10 fpc0 CMSNG:
Fatal ASIC error, chip TQ fpc0 TQCHIP 0: CM cache parity Fatal interrupt has occurred
181 time(s) in 180010 msecs TQCHIP 0: CM cache parity Fatal interrupt has occurred
181 time(s) in 180005 msecs PR1089955
•
Incorrect ESH checksum computation with non-Zero Ethernet padding in the Junos
MX Series router. PR1091396
•
The mspmand process might crash 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 lots of
retransmissions and reordered packets PR1092655
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
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 retransmissions 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
•
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 configuration statement 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
•
On Junos OS-based platform, 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.5 Mpps), the packet re-ordering may occur. PR1098776
•
On MX Series-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
•
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
•
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
MPCs. This includes MX-Series with MPC1, MPC2 and all mid-range MX-Series routers.
PR1108826
Copyright © 2016, Juniper Networks, Inc.
201
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Infrastructure
•
When "show version detail" cli command has been executed, it will call a 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: user@hostA> 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-initializing 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
Interfaces and Chassis
•
Power-off by pushing the Offline button on the master Routing Engine causes lots of
packets to be although GRES/NSR is configured. FPC gets rebooted after Routing
Engine switchover, which also causes traffic loss. PR1034164
•
Configuring ODU FRR on 2x100G DWDM under otn-options could result in an FPC
core.PR1038551
•
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 arriving on the AE interface instead of the 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 wereset
together on pm3393 chip driver software, so even before the copy of stats to shadow
registers happened, clear was happening which used to go unaccounted. PR1056232
•
On M120 router with scaled configuration, when restarting an FPC, the chassis
management daemon (chassisd) might crash if it didn't get FPC offline ACK from one
of the FEBs in time. PR1059475
•
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
•
202
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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 routes 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
•
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
•
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
•
On MX Series Virtual Chassis (MX-VC) platforms, 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 rebooting the
hosted Modular Port Concentrator (MPC). PR1080032
•
On MX-VC with SCB (no Enhanced SCB equipped), if the fabric redundant-mode is
not explicitly configured, after rebooting whole VC, the VC-Mm will stay in Redundant
mode but not Increased-bandwidth mode. PR1080301
•
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) scenarios, 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 swith "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 and the
Copyright © 2016, Juniper Networks, Inc.
203
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
expected local GRES and a reboot of the former master Routing Engine might not
happen on the VC-B, and some of the FPCs on it might be stuck in "present" state and
eventually rebooted. PR1086316
•
When an interface on SFPP module in MIC is set to disabled, after pulling out the SFPP
and then inserting it, the remote direct connected interface might go up unexpectedly.
PR1090285
•
After removing a child link from AE bundle, in the output of "show interface <AE>
detail", the packets count on the remaining child link spikes, then if we add the previous
child link back, the count recovers to normal. PR1091425
•
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. ------------------------------------------------- lab@router_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
J-Web
204
•
Junos: Multiple vulnerabilities in J-Web (CVE-2016-1261); Refer to
https://kb.juniper.net/JSA10723 for more information. PR1085428
•
Junos: Multiple vulnerabilities in J-Web (CVE-2016-1261); Refer to
https://kb.juniper.net/JSA10723 for more information. PR1085470
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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
Layer 2 Features
•
BGP peer configured between two routers over an lt (logical tunnel) interface, if
deactivating and activing at scaled configuration a few times, in rare conditions, the lt
interface might reject all the ARP reply packets. Hence, the ARP resolution does not
happen over this interface, so the unicast routes are not in the correct states, and a
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 incorrectly when the AE member link is connected
to a different device; which 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
the ring is in idle condition. Changing ring interface MTU while a ring is not in idle state
may result in change in the forwarding state of the interface, 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 following configuration: .
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:
Copyright © 2016, Juniper Networks, Inc.
205
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 a high amount of TCN
flooding. This problem is visible after the changes done in Release 11.4R8 onwards
which propagates TCN BPDU immediately 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
•
V44 defines the next generation of Juniper Network Fabric using MX Series router 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 not to come up. PR1101266
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 the 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 the Packet Forwarding Engine.
PR1058190
•
LDP peer will not advertise all labels to downstream LDP neighbor/s on rare occasions.
PR1058694
206
•
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 configuration statement or route churn, the memory might be
exhausted which leads to the rpd process crash. PR1061840
•
The point-to-multipoint (P2MP) label-switched path (LSP) is unable to be re-establish
after certain links are down. This issue might be encountered when the links 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 the next-hop interface along the primary path. However it doesn't
consider the SRLG group on the next-to-next-hop interface to adequately provide a
diverse path between primary and node-protected bypass. PR1068197
•
In scaling l2circuits environments, 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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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 configuration statements, none of the following configuration statements 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 the 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
•
On dual RE platform with GRES, the kernel synchronization process (ksyncd) may
crash on the backup RE when adding of route pointing to indirect nexthop on system.
PR1102724
Platform and Infrastructure
•
On April 22nd, 2009 FreeBSD announced that the db interface in libc in FreeBSD 6.3,
6.4, 7.0, 7.1, and 7.2-PRERELEASE does not properly initialize memory for Berkeley DB
1.85 database structures, which allows local users to obtain sensitive information by
reading a database file. Refer to JSA10756 for more information. PR442580
•
When the Network Configuration Protocol (NETCONF) service is used on the device,
after the NETCONF session is established, because all the output that contains <error>
tag might be incorrectly converted into <rpc error>, the management daemon (mgd)
may crash on the device. As in the following example, the output that contains the
<error> tag may lead to the crash: user@re0> show subscribers address 1000 | display
xml .. <error junos:style="input-error"> <<<<<< The output contains <error> tag and
may trigger the crash. PR975284
•
On a router with point-to-point(P2P) SONET/SDH interface, when a P2P interface is
disabled, the corresponding host route might still be kept in the forwarding table, if a
ping operation is performed, instead of returning message "No route to host" the
message "Can't assign requested address" might be seen. PR984623
•
On MX Series Virtual Chassis (MX-VC) platforms, mirroring of OAM packets may not
work as expected if the OAM packet traversing through multiple Packet Forwarding
Engines (for example, the mirrored port and VCP port are on separate Packet Forwarding
Engines). PR1012542
•
In EVPN scenarios, MPC may crash with core-dump when any interface is deleted and
then add that interface to an aggregated Ethernet bundle or change the ESI mode
from all-active to single-active. PR1018957
•
Junos: Multiple privilege escalation vulnerabilities in Junos CLI (CVE-2016-1271); Refer
to https://kb.juniper.net/JSA10739 for more information. PR1019669
•
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
•
Changes to the fowarding-table firewall filter list can cause an FPC/TFEB crash. The
fowarding-table firewall filter list can be composed of user configured filters under the
"forwarding-options" stanza but it can also contain auto-generated filters (also known
Copyright © 2016, Juniper Networks, Inc.
207
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
as "internal" filters or "implicit" filters) and are needed by certain features. For example
the "services traffic-load-balance" feature makes use of auto-generated
fowarding-table filters and also the "forwarding-options dhcp-relay" feature makes
use of auto-generated fowarding-table filters. PR1039003
•
On MX Series routers 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. Another application exposed is Layer
2 family any output port-mirror configuration. On T4000 with FPC type 5, when these
cards are processing any packets sizes between 133B-148B in certain sequences results
in incorrect cell packing handling. PR1042742
•
Due to a defect in the Junos OS 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
a considerable number of .perm/.env files get accumulated under /var/run, the issue
is seen with telnet users who are not able to perform permitted operations on the
router, post-login. PR1047609
•
Under very rare situations, Packet Forwarding Engines on the following line cards, 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
line card or chassis reload is required to correct the condition. PR1058197
•
With the configuration "extend-size", if the user loads and commits the scaled
configuration (in this case, 250K Unique Prefix list policy options), then deletes the
configuration statement "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 get stressed with a huge number of audit logs to be sent to the
accounting server, which might cause auditd to crash. PR1062016
•
Chassisd had a software problem in FPC OFFLINE event handling code. When multiple
offline events for a single FPC are coming in short period, chassisd might wrongly stop
handling FPC offline process in the middle. As a result, the FPC and fabric state for
that FPC will remain abnormal. This PR has resolved the problem. Now chassid will
correctly continue the FPC offline process even for such condition. Resolved-In: 12.3R10
13.3R7 14.1R5 14.1X50-D100 14.2R4 15.1R1 15.1X49-D10 PR1063786
•
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 a future time stamp.
PR1067307
•
208
In Junos release 13.3R6 or 14.2R3, for PPPoE subscribers over the aggregated Ethernet
(ae) interface, the output of "show interface statistics <pp> detail" command shows
the ingress/egress traffic statistics for the aggregate interface instead of the statistics
for PP/DEMUX logical interface. PR1069242
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
With "shared-bandwidth-policer" on an aggregated Ethernet interface; if a member
interface flapped, the NPC to which the interface belongs may restart. The similar issue
may also happens when changing firewall policer configuration. PR1069763
•
Junos: Multiple privilege escalation vulnerabilities in Junos CLI (CVE-2016-1271); Refer
to https://kb.juniper.net/JSA10739 for more information. PR1069867
•
Junos: Multiple privilege escalation vulnerabilities in Junos CLI (CVE-2016-1271); Refer
to https://kb.juniper.net/JSA10739 for more information. PR1069873
•
If with about 1M routes on an MX Series router, there might be more than 1-second
(about 1.3s) packets dark window during unified ISSU. PR1070217
•
If port-mirroring and VRRP over ae-irb are 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
•
When inline-sampling is enabled, in race conditions, if a packet gets corrupted and the
corrupted packet length shows 0, it may cause a "PPE_x Errors thread timeout error"
and eventually cause the MPC card to crash. PR1072136
•
VRRP advertisements might be dropped after enabling delegate-processing on the
logical tunnel (lt) interface. It would result in a 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 the destination’s
MAC address FFFF:FFFF:FFFF (e.g., ARP packet). PR1073536
•
In VXLAN environment, BUM traffic will be duplicated, the duplicate amount depends
on how many Packet Forwarding Engines are included in that bridge domain. E.g If
there?re 2 physical interfaces located in 2 different Packet Forwarding Engines in bridge
domain , traffic leaving vtep will triple due to this issue. That is one copy from ingress
Packet Forwarding Engine and other two copies from egress Packet Forwarding Engines
where 2 physical interfaces are present. Issue is fixed on 14.1R5, 14.2R4, 15.1R2, 15.1R1
and above. PR1073778
•
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
•
On this PR, It removes unwanted resolve filter log in ichip/Packet Forwarding Engine
side and it was fixed since 12.3R10. PR1076563
•
When an SFB on MX2020/MX2010 is experiencing a hardware issue, the SPMB might
crash and cause FPC to reboot. Now with the fix, the bad Hardware issue will be handled
gracefully and not crash. PR1077074
Copyright © 2016, Juniper Networks, Inc.
209
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In hierarchical class of service (H-CoS) environments, when the subscriber logs out
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
•
From Junos 13.3, configuration changes like activating "fast-lookup-filter", adding or
deleting "interface-specific" or any other filter property, adding or deleting any term,
or changing any match condition in any term in the filter, which updates the firewall
filter in a rare sequence might result in loss of DMEM and kernel memory resources or
some free error messages. This issue only impacts Trio-based line card and occurs in
rare cases. The following log messages might be observed from Junos 13.3 [LOG: Err]
jnh_free(10040): ERROR [FW/0]:1 Paddr 0x00400000, addr 0x0, part_type 0call_stack
0x404906b4 0x418ecdbc 0x418ed2e0 0x418baca0 0x418becc8. And the following
log messages might be observed from Junos 14.2 [LOG: Err] FREE ERR FW[0]: FW, 1
dw (1 blk) @ PA 0x7c63f00d addr 0x23f00d PR1077338
•
Junos: Lazy race condition in RPC allows an authenticated user to improperly elevate
privileges (CVE-2016-1267); Refer to https://kb.juniper.net/JSA10730 for more
information. PR1078027
•
On MX Series-based platforms, when learning the MAC address from the pseudo-IFL
(for example, label-switched interface), if the MAC address is aged out in the source
FPC where the MAC got learned, 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 might be deleted first from the egress Packet
Forwarding Engine but get added again during these 2-3 millisecond time intervals.
(As there is continuous traffic coming on the egress FPC destined to this MAC, the MAC
query is generated and sent to the Routing Engine and source FPC. Since the source
FPC has not yet processed the MAC-deleted message, it sends the response, so stale
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
•
On Trio MPC, the log message are printed "ddos_clear_one_work_queue: can't return
an item to store 4" if DDos violations for all hostbound traffic that exceed bandwiths.
PR1082298
•
MPC is showing the following log messages and will generate core:
“jnh_private_mem_pool_free(898): No private mem_pool for 0x00300000/00100000”
PR1081855
210
•
When an MX Series 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 the 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 the LU/XL
ASIC chip with the MQ/XM ASIC chip. These events will corrupt the state in MQ/XM
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
and lead to an MQ/XM wedge. The MQ/XM wedge would cause fabric blackhole and
finally reboot the line card. PR1082932
•
On MX Series router with MPCs/MICs , 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 OS Releases 13.3R3, 14.1R1, and 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 unified ISSU from an image
without the feature to an image with this feature, all MPCs might crash. PR1085357
•
With MX Series routers with FPC, load balance hash seed will be changed after the
unified ISSU. Since the hash seed value will be reverted to the original value by rebooting
FPC, there would be a 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, and 14.2R1-14.2R3.
PR1086286
•
The prompt for the SSH password changed in Junos OS 13.3 Release, from "user@host'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
•
Junos: A race condition in the Op script Op URL option allows an authenticated remote
attacker to fully compromise the system (CVE-2016-1264); Refer to
https://kb.juniper.net/JSA10725 for more information. PR1088339
•
On MX Series router with MPCs/MICs or T4000 FPC5, a 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
the forwarding-options hierarchy level. PR1088501
•
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
FIB-local FPC. PR1092627
•
When an interface on an MQ-based FPC is going to link down state, in-flight packets
on interface transmit path will be stuck on the interface and never drained until the
interface comes up again. As a result, a small number of such stacked packets will be
sent out when the interface is going to the UP state. In some cases it might also trigger
Host Loopback:HOST LOOPBACK WEDGE DETECTED IN PATH ID [x] reported and
traffic forwarding stopped for all interfaces belonging to this Packet Forwarding Engine.
Once the interface comes back up, packet forwarding will continue for all interfaces
and the Host Loopback wedge alarm gets cleared. The following FPCs are exposed to
this symptom: MPC 3D 16x 10GE, MPC1 or MPC2. PR1093569
•
On MX2020 or 2010 routers, an SPMB core file will be seen if there are bad XF chips
(Fabric chip) on the SFB, which might trigger Routing Engine/CB switchover. PR1096455
•
On MX Series routers 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
Copyright © 2016, Juniper Networks, Inc.
211
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
traffic rate is high (for instance, higher than 3.5 Mbps), the packet re-ordering may
occur. PR1098776
•
On MX Series routers with MPCs/MICs,, when the prefix-length is modified from a
higher value to a 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
•
The "shared-bandwidth-policer" configuration 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
Seriesplatform with pure trio-based line cards. The bandwidth/burst-size of policers
attached to Aggregated Ethernet interfaces are not dynamically updated upon member
link flaps. PR1098486
•
Starting in Junos OS Release 14.1 and later, IPv6 mobility packets with the Heartbeat
option such 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
packets 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
212
•
When "shared-bandwidth-policer" is configured with aggregate Ethernet (AE) has
more than one member link on the same Packet Forwarding Engine and the policer is
configured with "physical-interface-policer" configuration 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 filter with a policer is referenced by multiple IFLs of the same interface (A),
with traffic coming into that interface A and going out from another interface B,
whenever the policer is updated (for example, deactivating and activating interface
A. Or adding/deleting AE legs when A is an AE interface and shared-bandwidth-policer
is configured), it might be seen that there is counter statistics for the counter which is
placed in the ingress direction of interface C, even though interface C is an unrelated
interface which is not in the traffic path. Also FPC core dump and FPC going offline
might be seen. PR1106887
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Routing Policy and Firewall Filters
•
In Class-of-Service (CoS) environments, there is a possibility (happened twice so far
and not reproducible in the lab) that the routing protocol process (rpd) may crash
because the CoS memory getting incorrectly freed and then allocated again. PR1062616
Routing Protocols
•
On M and MX Series platforms with dual RE environment, when nonstop active routing
(NSR) and graceful-switchover (GRES) are enabled, during internal pressure test with
GRES operations, in very rare condition, the Routing protocol daemon (rpd) might
crash and a core-dump would be generated. PR1019052
•
Deletion of a routing-instance may lead to a routing daemon crash. This may happen
if the routing-instance's Routing Information Base (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 environments, in the situation
where the router is being used as the rendezvous point (RP) and 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) already exists, if
the (S,G) entry is learned 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 the (*,G) route. PR1073773
•
In multi-topologies IS-IS scenarios, there is a huge difference between estimated free
bytes and actual free bytes when generating LSP with IPv6 prefix. It might cause LSP
fragment exhaustion. PR1074891
•
Receipt of a crafted IGMPv3 protocol message can create a denial of service to a
portion of a multicast network. This issue only affects IGMPv3. IGMPv2 is unaffected
by this vulnerability. See https://kb.juniper.net/JSA10714 PR1079503
•
In an MPLS L3VPN core network, enabled BGP Prefix-Independent Convergence (PIC)
Edge feature on a PE router, if the same VPN route is received with different multiple
exit discriminators (MEDs) via two route reflectors (RRs). When the BGP PIC evaluates
those two routes, it disregards the one with the higher MED, and hence fails to build a
multipath protection/backup path entry. PR1079949
•
When removing scaling BGP configuration, if the BGP sessions is holding stale routes
for the benefit of a restarting peer, the routing protocol process (rpd) may crash. As a
workaround, the administrator may use the CLI command "show route receive-protocol
bgp <peer address> extensive | match STALE" to find the existing stale routes. If no
STALE route can be found out, then removing the BGP configuration is safe. PR1081460
•
If a policy statement referred to a routing-table, but the corresponding routing instance
is not fully configured (i.e., no instance-type), committing 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
Copyright © 2016, Juniper Networks, Inc.
213
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
point (RP), the rpd process might permanently get stuck when multicast traffic is
received shortly after Routing Engine (RE) switchover. PR1083385
•
The rpd process might crash on both master and backup Routing Engines when a
routing instance is deleted from the configuration, if the routing instance is cleaned up
before the interface delete is received from the device control daemon (dcd). This is
a rare timing issue. PR1083655
•
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
•
When a 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 copied to a second table can't be deleted after routes were deleted in the
master table. This is a day-1 issue. PR1090760
•
When removing BGP Prefix-Independent Convergence (PIC) from the configuration,
the expected 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 the BGP session flaps or the route itself flaps. As a
workaround, we can use the "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 that AS4_AGGREGATOR attribute is only received when
the aggregator has 4-byte AS, but this peer only supports 2-byte AS), NSR
synchronization with the standby RE would fail, causing the session to be constantly
bouncing on the standby RE (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 the configuration statements from
higher levels. This behavior conforms with our current behavior of family configuration,
which is that any configuration at a lower level is honored and the higher level
configuration is reset. PR1094499
•
The OpenSSL project has published a set of security advisories for vulnerabilities
resolved in the OpenSSL library in June and July 2015. Junos OS is affected by one or
more of these vulnerabilities. Refer to JSA10694 (http://kb.juniper.net/JSA10694) for
more information. PR1095598
•
When BGP routes have multiple protocol next hops, including discard/reject and other
IGP next hops, the discard/reject next hop will be selected as BGP next hop, which will
cause traffic loss. PR1096363
•
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
214
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Services Applications
•
In IPsec environments, after performing the RE switchover (for example, performing
graceful Routing Engine switchover) or chassis reboot (that is, whole device is powered
down and powered UP again), because the key management daemon (kmd) may be
launched before the RE mastership is finalized, it may stop running on the new master
RE. PR863413
•
The session-limit-per-prefix feature for the MX Series DS-Lite 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
occurs, 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 being
able to log in. 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
•
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 stateful firewall environments, due to a null pointer check bug, the
MS-DPC might crash every few hours. Note that this is a regression issue. PR1079981
•
When using a Multiservices DPC (MS-DPC) for Carrier-Grade Network Address
Translation (CGNAT), if in an HTTP flow, in rare condition, an IPv4 flow is treated as
an IPv6 flow. However IPv6 flow objects are treated differently in the Junos Code and
as a result the MS-DPC might crash due to memory allocation failure. There is no
workaround, but the chances of hitting this issue is 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 an 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 a 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 processing the TFTP packets. PR1091179
Copyright © 2016, Juniper Networks, Inc.
215
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
On M Series platforms, in a Layer 2 Tunneling Protocol (L2TP) network server (LNS)
environment, not all attributes (Missing NAS-Identifier, NAS-Port-Type, Service-Type,
Framed-Protocol attributes) within the Accounting-Request packet are sending to the
RADIUS server. PR1095315
•
If MS-DPC is used in a CG-NAT environment, in a very rare condition, when the MS-DPC
tries to delete a NAT mapping entry (e.g., entry timeout), an error might occur and the
MS-DPC might get rebooted and then dump a core file. PR1095396
•
Some values of the MIB object jnxSrcNatStatsEntry might be doubled when AMS (or
rsp) interface and NAT are configured together. PR1095713
User Interface and Configuration
•
Customer wants visibility PR1029477
VPNs
•
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 the 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 be avoided: * 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
•
With NSR, RPD on backup Routing Engine may crash and generate a memory dump
when attempting to allocate an MPLS label for L2circuit. This can happen, for example,
after configuring new l2circuit on a busy system. PR1068399
•
On a dual Routing Engine, if the MVPN protocol itself is not configured, and nonstop
routing is enabled, the show command "show task replication" on the master Routing
Engine will list the MVPN protocol even though it is not configured. Other than the
misleading show output which may be slightly confusing to the user/customer, there
is no functional impact due to this issue. There is no workaround available. PR1078305
Resolved Issues: 14.2R3
Class of Service (CoS)
216
•
For an ATM interface configured with hierarchical scheduling, when a
traffic-control-profile attached at the ifd (physical interface) level and another output
traffic-control-profile at the 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 stops working after Routing Engine switchover , this
behavior has been corrected in 13.3X2 ,13.3R7,14.1R5,14.2R3,13.3R6 and 15.1 . Issue comes
when MPC reboots for any reason with forwarding-class-accounting configured on
AE/AS interface. In forwarding-class-accounting feature, counters are allocated based
on number of forwarding classes configured in MPC. In error case on MPC reboot, AE
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
interface is getting created before the message for configuring number of forwarding
classes in MPC comes. As a result while enabling forwarding-class-accounting feature
on AE interface, number of forwarding classes value in MPC is 0 and counters are not
allocated causing issue. Cause: Race condition when on MPC reboot AE interface
getting created before number of forwarding classes are configured. Fix: When number
of forwarding classes are set after MPC reboot, check for any AE interface with
forwarding-class-accounting configured and reprogram it. PR1060637
•
1. With “hierarchical-scheduler” configured at IFD level 2. Under class-of-service
hierarchy “output traffic control profile” configured at “interface-set” as well as IFD
level, for the same IFD/IFL. With the above two conditions met, when a Junos upgrade
is performed on a dual RE system the configuration validation check would fail on the
RE that is upgraded latter with the below error message. Error message: ?cannot
configure a traffic control profile for this ifl when a parent has a traffic control profile
that references a scheduler map: ifl xe-11/0/0.5000 refers to traffic-control-profile
TCP_PE-CE_30M. It is also a member of interface set xe-11/0/0_OTag=80 which has
traffic-control-profile TCP_PE-CE_80M which references scheduler-map SM_PE-CE?
conditon-1: lab-re1> show configuration interfaces xe-11/0/0 { hierarchical-scheduler;
<<< Condition-2: lab-re1> show configuration interfaces interface-set
xe-11/0/0_OTag=80 { interface xe-11/0/0 { <...>; } } lab-re1> show configuration
class-of-service interfaces interface-set xe-11/0/0_OTag=80 {
output-traffic-control-profile TCP_PE-CE_80M; <<< } <..> xe-11/0/0 {
output-traffic-control-profile TCP_Maxbuff; unit 5000 { output-traffic-control-profile
TCP_PE-CE_30M <<< } } PR1069477
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 MPC/MIC, the IPv6
GRE header would be de-encapsulated but the inner IPv4 packet would ends 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: This issue has been resolved.
•
If the template of the policer is changed (for example, change the bandwidth-limit
value of policer), shared-bandwidth-policer configuration statement may not function
properly anymore. PR1056098: This issue has been resolved.
General Routing
•
On MX Series platforms with Enhanced DPCs equipped, after router is 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 following L2Channel
error increases as ping packets are sent: user@router>show interfaces ge-*/*/*
extensive | match channel L3 incompletes: 0, L2 channel errors: 10, L2 mismatch
timeouts: 0. PR876456: This issue has been resolved.
•
The configuration statement “gratuitous-arp-on-ifup” should send a gratuitous ARP
on each unit of a physical interface, but in 12.3 and later versions, only the first unit is
seeing the configured behavior. PR986262: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
217
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In the dual Routing Engines scenario, in rare conditions, while executing GRES and
deleting interfaces at the same time, it is possible that a next hop delete message is
not sent to the rpd process, causing rpd to keep a next hop index (NHID) that the kernel
has already deleted. Later when the kernel allocates this NHID for next new next hop
and sends it to the rpd process, the rpd process might crash due to a duplicate NHID.
PR987102
•
In Ethernet VPN (EVPN) 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 remaining IRB subnet being advertised in
L3 routing which in turn attracts all L3 VPN traffic for the subnet. PR994909: This issue
has been resolved.
•
In the dual Routing Engines scenario with NSR configuration, the 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 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 a few seconds). PR1008508: This issue
has been resolved.
•
If with some groups has not been applied on a router, in some corner cases, the action
that load override configuration might cause the routing process (rpd) to crash.
PR1037527: This issue has been resolved.
•
On MX Series platform with nonstop active routing (NSR) is enabled, if with
switchover-on-routing-crash configuration statement configured, issuing the CLI
command "request system core-dump routing fatal" might not trigger RE switchover
and might cause rpd on master RE stuck in inactive. PR1000220: This issue has been
resolved.
•
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: This issue has been
resolved.
•
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 reused. 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: This issue has been resolved.
218
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
During ISSU on MX-VC platforms, there is a chance that the management process
(mgd) on both VC-M and VC-B considers itself as protocol backup, resulting in a reboot
of the entire VC. PR1020606: This issue has been resolved.
•
On MPC5E line cards, if a firewall filter with large-scale terms (more than 1300 etc.)
is attached to an interface, traffic drop might be seen. PR1027516: This issue has been
resolved.
•
Using jnxoptIfOTNPMFECIntervalTable and jnxOpticsPMIntervalTable, it was not
possible to walk these tables from the middle before this fix. PR1039030: This issue
has been resolved.
•
Incorrect SNMP interface index (index 0) is given to the VCP interface. Due to the wrong
index value, the VCP interface description does not appear in SNMP interface table.
PR1044331: This issue has been resolved.
•
On MX Series routers with one of the following protocols configurations, flapping the
protocols will trigger the Composite Next-hop change operation. In rare conditions,
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: This issue has been
resolved.
•
Once default route 0.0.0.0/0 is added, deleted, or changed, the PFEMAN thread running
on the MPC/FPC5 needs more than 600 msec 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: This issue has been resolved.
•
For PTX router, the unilist next-hop member will have a 'replaced' status on Packet
Forwarding Engine (PFE) after interface flapping with ARP timeout. While the problem
is happening, routing-table will display correct 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: This issue has been resolved.
•
This problem is because of a race condition, where other FPCs are not able to drain
"which is 1 second" Fabric Streams connecting to the FPC which is going offline. With
this situation, even when FPC comes online, other FPCs which have observed the
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
the error message "xmchip_dstat_stream_wait_to_drain" is a recovery. PR1052472: This
issue has been resolved.
•
VCP links do not stay up during the unified ISSU. This causes traffic loss and control
plane packet losss which can lead to control protocol flaps. PR1054344: This issue has
been resolved.
•
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: This issue has been resolved.
•
IFCM error messages may occur in logs when it is not used. We lowered the severity of
the message to avoid confusion. PR1057712: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
219
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
When enabling pseudowire subscribers, the "show subscribers extensive" command
does not display CoS policies applied to the subscriber interface. This issue was fixed
in 13.3R6, 14.1R5 and 14.2R3. PR1060036: This issue has been resolved.
•
Due to an incomplete fix, in releases containing the PR869773 fix, rate limit drops are
seen for ingress queuing even though rate-limit is not configured or supported for
ingress. PR1061256: This issue has been resolved.
•
On MX Series platforms, after performing unified in-service software upgrade (ISSU)
to 14.2R1/14.1X50-D40 and later releases, the clock synchronization might be stuck in
"freerun" and the Enhanced SCB (SCBE) clocking interface might appear as down.
PR1065308: This issue has been resolved.
•
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) may fail after performing unified
In-Service Software Upgrade (ISSU). The interrupt might got prevented after performing
unified ISSU due to disable the interrupt registers before ISSU but never restored after.
PR1059098: This issue has been resolved.
•
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 PFE FPC, the TCP packets might
be out of order, and packet re-ordering would occur. This reduces the application level
throughput for any protocols running over TCP. PR1049613: This issue has been resolved.
•
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: This issue has been resolved.
•
In the scenario where a router acts as both egress LSP for core network and BRAS for
subscribers, RSVP-TE sends PathErr to the 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:
This issue has been resolved.
•
In IPv6 environments, after enabling the 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 exact, the IPv6 router may not only reply to the IPv6 host an RA as
unicast to its link local address, but also send the RA as multicast to all nodes groups
(Multicast Address: ff02::1). The sample configuration could be as follows: user@router>
show configuration protocols router-advertisement interface ge-1/0/3.400 { ...
solicit-router-advertisement-unicast; <<<<< "solicit-router-advertisement-unicast"
feature is enabled ... } PR1056599: This issue has been resolved.
•
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 to the label value of LDP. PR1058146: This
issue has been resolved.
•
220
If with accounting/sampling enabled, an unnecessary update from the routing protocol
process (rpd) to the route record database might be triggered by certain configuration
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
change. This process causes jump in CPU utilization of all Packet Forwarding Engines.
PR1002107: This issue has been resolved.
•
On PTX or T Series platform running Junos OS Release 12.1 or later, for interfaces
connected via optical systems like DWDM, when the interface is admin disabled, there
might be a delay (300-400 msec) for the system to detect the event during which
time, traffic blackhole might be seen. Please note if you disable the interface by breaking
the Rx or Tx link, the issue will not happen. PR1043762: This issue has been resolved.
•
On PTX series routers, the interrupt-driven link down detection may stop working.
When the line card is receiving multiple back-to-back fault in very short duration (no
matter from remote or local), it may fail to detect all the received interrupts, and this
failure may cause delay of the link-down detection (for example, it may take PTX
~300ms to make interface down). PR1060279: This issue has been resolved.
•
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 the 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: This issue has been resolved.
•
On MX Series platforms with MS-MPC/MS-MIC, if the "dump-on-flow-control"
configuration statement is configured, traffic loss and the mspmand process crash
might be observed when the MS-PIC comes up with traffic. PR1037086: This issue has
been resolved.
•
When the CPU usage is very high (e.g., 100%) on a Routing Engine, the MS-MIC might
get stuck due to kernel deadlock, which triggers the card to crash and generate a core
file. PR1038026: This issue has been resolved.
•
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, a multiservices PIC management
daemon core file is generated. PR1019996: This issue has been resolved.
•
Incorrect flow count is reported in the field 'count' of the V9 header in all the packets
sent to the collector. PR1050543: This issue has been resolved.
•
On MX104 routers with SONET/SDH OC3/STM1 (Multi-Rate) MIC. In rare conditions,
if the MIC is unplugged from MX104, the Packet Forwarding Engine might crash, and
the traffic forwarding will be affected. These MICs as follows belong to the 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: This issue has been resolved.
•
For MLPPP interfaces on MX Series routers with MPCs/MICs, in some very rare
conditions, the received fragmented packets might be dropped. PR1041412: This issue
has been resolved.
•
In the PPP dual-stack subscribers environment, in rare conditions, if bringing up 1000
dual-stack subscribers quickly, the PPP negotiation might fail. When PPP retries
negotiation, all subscribers fully establish. PR1050415: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
221
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In subscriber management environments, the Berkeley Database (DB) may get into a
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 the database being blocked by the 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 requests, 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: This issue has been resolved.
•
In subscriber management scenarios, when a dynamic VLAN (DVLAN) demux interface
configured on MX Series routers, the interface may get in a stuck stat. It could be
observed that the statistics of demux0 may stop incrementing. This is because the
Session Database (SDB) may incorrectly calculate the number of subscribers over
DVLANs. When the issue occurs, for example, the router may not able to process any
PPPoE Active Discovery Initiation (PADI) packets, and fail to establish the PPPoE
session. PR1054914: This issue has been resolved.
Interfaces and Chassis
•
REG_ERR errors might be observed on MX Series routers with Enhanced SCBs and a
mix of MPC and DPC cards. PR821742: This issue has been resolved.
•
Ether OAM or DPC 10ge interface module changed link-fault status from down to up
after being changed link status to down by "asynchronous-notification". PR973840:
This issue has been resolved.
222
•
The fix is available in 14.1R4 and 14.2R2. Need to apply the workaround before ISSU in
14.1 prior to R4 and in 14.2 prior to R2. PR997255: This issue has been resolved.
•
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: This issue has been resolved.
•
If DPCE 20x 1GE + 2x 10GE X card is present in the chassis, BFD sessions over AE
interfaces may not be distributed. PR1032604: This issue has been resolved.
•
Some duplicate entries are reported in jnx-chas-defines.mib. This patch removes the
duplicate entries to fix the issue. PR1036026: This issue has been resolved.
•
Configuring ODU FRR under otn-options for 2x100G DWDM PIC is unsupported
command on PTX router, wrongly add such configuration could result in an FPC crash
and restart. PR1038551: This issue has been resolved.
•
PTX with 2x100Gig PIC might return incorrect values for
jnxOtnIntervalOtuFec15minCorrectedErrors and
jnxOtnCurrentOtuFec15minCorrectedErrors. This is happening because 2x100Gig PIC
is not supporting jnx-otn.mib. Instead please use jnx-ifotn.mib or jnx-bl.mib. With this
fix, the jnx-otn.mib should not return anything on 2x100Gig PIC. $ snmpwalk -v 2c -Obs
-c public [IP address] jnxOtnIntervalOtuFec15minCorrectedErrors
jnxOtnIntervalOtuFec15minCorrectedErrors = No Such Instance currently exists at this
OID $ snmpwalk -v 2c -Obs -c public [IP address]
jnxOtnCurrentOtuFec15minCorrectedErrors jnxOtnCurrentOtuFec15minCorrectedErrors
= No Such Instance currently exists at this OID On 4x100Gig PIC using jnx-otn.mib for
jnxOtnIntervalOtuFec15minCorrectedErrors and
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
jnxOtnCurrentOtuFec15minCorrectedErrors, the correct values are reported if the error
rate is below 900. Otherwise the CLI values will give us the right data. PR1038577: This
issue has been resolved.
•
On Ethernet PICs with longer hold-down timer configured, a flapping interface within
the hold time might cause traffic loss longer than the hold period. PR1040229: This
issue has been resolved.
•
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 anymore. PR1041811: This issue has been resolved.
•
“clear interfaces interface-set statistics all” fails due to memory limitation. PR1045683:
This issue has been resolved.
•
On MX Series routers (platforms) with Enhanced Switch Control Board (SCBE), when
the fan tray is inserted or pulled out, the chassisd process might crash. PR1048021: This
issue has been resolved.
•
When configuring the Virtual Router Redundancy Protocol (VRRP) on an interface
which is included in a routing-instance via applying groups settings, if changes are
made to the interface, the VRRP process (vrrpd) memory leak might be observed on
the device. PR1049007: This issue has been resolved.
•
dcd is cored by configuring the IPv6 address on fxp0.0 with master-only option under
interfaces configuration. PR1049450: This issue has been resolved.
•
When Inherit is part of a 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: This issue has been resolved.
•
In a Virtual Router Redundancy Protocol (VRRP) environment, after restarting the FPC,
due to the Router Advertisement (RA) deletion being incorrectly sent to routing protocol
process (rpd) by the 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 can be sent out.PR1051227: This issue has been resolved.
•
Two redundant logical tunnels (rlt) interfaces are configured with the configuration
statement "per-unit-mac-disable" enabled. After configuring the second one, the first
rlt interface goes down: rlt0 { logical-tunnel-options { per-unit-mac-disable; <<<<<<
} } PR1055005: This issue has been resolved.
•
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: This issue has been resolved.
•
After performing a unified in-service software upgrade (ISSU) on the MX Series Virtual
Chassis (MX-VC) platform, all physical interfaces may go down. The interfaces remain
Copyright © 2016, Juniper Networks, Inc.
223
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
down until a graceful Routing Engine switchover (GRES) is performed. PR1055327: This
issue has been resolved.
•
When a dynamic PPPoE subscriber with targeted-distribution 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 can't visit internet after the crash. This is a rare issue and not easy to be
reproduced. PR1056675: This issue has been resolved.
•
In subscriber management environment, PPP client process (jpppd) might crash as a
result of a memory allocation problem. PR1056893: This issue has been resolved.
•
In multichassis link aggregation groups (MC-LAGs) environments, 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 traffic forwarding to be
affected. PR1059453: This issue has been resolved.
•
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
side does not remove the flap link from AE bundle and it remains UP. This might cause
a network-wide loop, resulting in traffic outage until manual intervention. PR1061460:
This issue has been resolved.
•
After chassis restart or non graceful RE switchover, few VRRP sessions may start
sending VRRP packets while still in VRRP backup state. PR1062929: This issue has been
resolved.
•
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: This issue has
been resolved.
Layer 2 Features
•
LDP-VPLS with BGP autodiscovery stays down after a GRES event when NSR is
enabled. PR1046887: This issue has been resolved.
•
On multiple Routing Engines systems 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: This issue has been
resolved.
224
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
After change the way of getting 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 because the site ID get by "automatic-site-id" may conflict with
the site ID which was configured as the fixed site ID on other sites. PR1054985: This
issue has been resolved.
Layer 2 Ethernet Services
•
If a customer is using SNMP and performs an snmpwalk on the DHCP binding table
not all of the entries may be displayed. This fix resolves that issue so that bindings for
all ip addresses are displayed. PR1033158: This issue has been resolved.
•
In DHCP dynamic subscriber management scenarios, 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: This
issue has been resolved.
•
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 128 MB.
PR1045004: This issue has been resolved.
•
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: This issue has been resolved.
•
When the MX Series router acts as the Virtual Extensible Local Area Network (VXLAN)
Layer 3 gateway, the integrated routing and bridging (IRB) interfaces are configured
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:
This issue has been resolved.
•
After FPC is rebooted, the filter under the Packet Forwarding Engine of ERPS bridge
domain might program the incorrect ifl index, which will cause the router to be unable
to receive any ERPS packets. PR1070791: This issue has been resolved.
MPLS
•
Error "tag_icmp_route:failed to find a chain composite ahead of fwd nh" might be
observed when doing traceroute. PR999034: This issue has been resolved.
•
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 process (rpd). PR1036452: This issue has
been resolved.
•
After upgrading Junos OS release to Junos OS release 13.2 or later from previous
releases, logical-system cannot start and run. The rpd continuously crashes every time
when trying to deactivate/activate the logical-system. PR1044781: This issue has been
resolved.
Copyright © 2016, Juniper Networks, Inc.
225
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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 provides link protection instead of node protection. PR1045055: This issue has
been resolved.
•
In NG-MVPN extranet scenarios, if there are mix of VT interface and LSI (vrf-table-lable
is used) interfaces on NG-MVPN egress node, after changing some vrf policies, the
routing daemon (rpd) might crash and reset. PR1045523: This issue has been resolved.
•
In LDP link protection which is protected by a dynamic RSVP LSP scenario, when flaping
the interface having LDP link-protection enabled, the rpd process might crash on the
backup RE as soon as the bypass LSP is established. PR1053426: This issue has been
resolved.
•
On M/MX/T/PTX Series routers, dynamic-rsvp-lsp is configured under interface
link-protection hierarchy level. After interface flap, the bypass LSP does not come up.
PR1054155: This issue has been resolved.
•
Please see CVBC section PR1054491: This issue has been resolved.
•
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 issue has been resolved.
•
This is a regression issue on all Junos related to a timing factor. When an 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: This issue has
been resolved.
•
From Junos 13.2 onwards, the "load-balance-label-capability" configuration statement
is introduced to enable the router to push and pop the load balancing label and causes
LDP and RSVP to advertise the entropy label TLV to neighboring routers. MX, T4000
and PTX platform have the capability and is reflected in their default forwarding-options
configuration. A software defect is found in the way Entropy Label Capability (ELC)
TLV is encoded in the LDP label mapping message. It might cause the LDP session
between routers go down. PR1065338: This issue has been resolved.
•
Bypass enabled with optimize-timer will flap during every re-optimization event.
PR1066794: This issue has been resolved.
•
226
When a primary LSP gets re-routed due to better metric, Link/Node protection for this
LSP is expected to come up within 7 seconds provided the bypass-lsp protecting the
next-hop link/node is already available. However in some corner cases, the Link/Node
protection for re-routed primary LSP will not come up within 7sec even with bypass-lsp
availability. The PR fixes this issue and reduces the delay of associating bypass-lsp
with primary-lsp from 7 seconds to 2 seconds. PR1072781: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Network Management and Monitoring
•
Customer requested visibility PR1043995: This issue has been resolved.
•
If the size of 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 the dcd process unable to start anymore, in the same time,
interface ports will be down and a "thrashing" error will be seen. PR1047330: This issue
has been resolved.
•
SNMP MIB walk jnxMac does not return value with et- interfaces on
MPC3/MPC4/MPC5/MPC6 PR1051960: This issue has been resolved.
•
There is no specific counter name in the MIB2D_COUNTER_DECREASING syslog
message PR1061225: This issue has been resolved.
•
SNMP queries for LAG MIB tables while a LAG child interface is flapping, may cause
mib2d grow in size and eventually crash with a core file. Mib2d will restart, and recover
by itself. PR1062177: This issue has been resolved.
Platform and Infrastructure
•
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 this may impact billing. PR886222: This issue has been resolved.
•
For inline BFD over aggregated Ethernet (AE) interface which member links are hosted
on different FPCs, BFD packets coming on ingress line card will be steered to anchor
Packet Forwarding Engine (PFE) through fabric. If FPC reconnect to master RE (such
as RE switchover operation), the inline BFD session punts the BFD packet to host, the
BFD packet should go through loopback interface filter of VRF on which it is received.
But in this case, the BFD packet might hit the wrong loopback interface filter from the
wrong routing-instance since the VRF information is not carried across fabric. PR993882:
This issue has been resolved.
•
BFD session within default routing-instance are not coming up once inline-services
PIC is configured and fixed class-of-service forwarding-class is assigned. BFD session
operating in no-delegate-processing are not affected. PR999647: This issue has been
resolved.
•
CPQ RLDRAM ECC single- and double-bit error will generate CM alarm. The "show
chassis alarms" command can be used to view CM alarms. 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: This issue has been resolved.
•
On MX Series platforms with scaled setup, after deactivating/activating or renaming
a bridge domain (BD) which has an IRB interface associated, the IGMP snooping
configured under the BD might not work anymore. This happens only when the router
is in "network-services enhanced-ip" mode. PR1024613: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
227
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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: This issue has been resolved.
•
Inline BFD sessions, through AE interface when only the member interface of the AE
is hosted on the MX Series MPC4E line card, might flap continuously. PR1029341: This
issue has been resolved.
•
On Trio 3D MPC, when there is a congested Packet Forwarding Engine destination, the
non-congested Packet Forwarding Engine destinations might experience an unexpected
packet drop. PR1033071: This issue has been resolved.
•
The micro BFD sessions won't come up if incoming untagged micro BFD packets contain
a source MAC where the last 12 bits are zero. PR1035295: This issue has been resolved.
•
configuration.yang had posix regex pattern, while as per the YANG RFC, it should have
been xml regex, that is why it had compilation issues. Now it is fixed. PR1040151: This
issue has been resolved.
•
When IRB interface is configured with VRRP in Layer 2 VPLS/bridge-domain, in corner
cases IRB interface may not respond to ARP request targeting to IRB sub-interface IP
address. PR1043571: This issue has been resolved.
•
In a scaled subscriber management environment, the output of the 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 caused inconsistency and the subscriber
management infrastructure daemon (smid) failed to register and no new subscribers
could connect. PR1045820: This issue has been resolved.
•
On T4000 and FPC Type 5-3D or TXP-3D platforms , BFD sessions operating in 100
msec intervals with default multiplier of 3 might randomly flap after the enhancements
implemented via PR967013. BFD sessions with lower intervals of 100 msec or higher
intervals are not exposed. The internal FPC thread, monitoring the High Speed Fabric
links, had a run time of longer then 100 msec. PR1047229: This issue has been resolved.
•
On MX Series platforms with Extensible Subscriber Services Management (ESSM)
subscribers configured using a Junos OS commit script, after performing a sequence
of operations repeatedly with the same set of configurations (subscribers
apply-macros'), like adding subscribers, then deleting same subscribers again, then
adding, then deleting again and again, 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: This issue has been resolved.
•
By default, after 16x10GE MPCs comes up, about 75% of queues were allocated to
support rich queuing with the MQ chip. Such allocation causes the MQ driver software
module to poll stats. Polling stats causes this rise in CPU usage. PR1048947: This issue
has been resolved.
•
228
For a Routing Matrix, if different Routing Engine (RE) 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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
em0 on LCC RE), then the OoB management interface configuration for LCC RE will
not be propagated from SCC/SFC RE during commit. PR1050743: This issue has been
resolved.
•
NTP.org has published a security advisory for multiple vulnerabilities resolved in ntpd
(NTP daemon) that have been assigned four CVE IDs. Junos OS 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: This issue has been resolved.
•
After committing the Network Time Protocol (NTP) configuration, if the number of
routing-instances per source-address exceeds 18, it may cause the 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 following sample
configuration: 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: This issue has been resolved.
•
On an MX Series router with MPCS/MICs with Junos 12.3R3 and later, 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 the default TPID 0x8100. This
might lead to traffic drop on the peer device if it is expecting a particular TPID (for
instance, 0x88a8) but it receives a different one. PR1059225: This issue has been
resolved.
•
Modifying the IEEE-802.1ad rewrite-rule on the fly might be unable to change
IEEE-802.1p ToS values for the inner VLAN in QinQ. PR1062817: This issue has been
resolved.
•
Observation domain ID in exported flow records is incorrect in 100G and 10G line cards
and in 200G 40X10G MPCs and 200G 40X100G 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 two bits of the TOS/TC bytes under the IPv4/IPv6 header are extracted
incorrectly as load-sharing input parameters, and this might cause unexpected load
balancing results. PR1066751: This issue has been resolved.
•
Firewall filters that 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: This issue has been resolved.
•
On MX Series routers, when using Trio-based FPC with feature inline sampling activated,
memory partition error messages and memory leak might be observed on the FPC. In
some cases, this issue only affects sample route-records but not regular Packet
Forwarding Engine routes or next-hops, however, in the extreme case, it is also possible
to cause the Packet Forwarding Engine failing in installing routes into forwarding
next-hops and hence traffic drop. On MX Series routers, when using Trio-based FPCs,
Copyright © 2016, Juniper Networks, Inc.
229
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Junos 13.3R5 14.1R4 14.2R1 or higher is exposed. On T4k or TXP-3D routers, when using
FPC-3D FPC's, Junos 14.2R1 or higher is exposed. PR1071289: This issue has been resolved.
•
VPLS filter applied under forwarding-options might drop a VPLS frame unexpectedly
when it is coming from an lt- interface. There is no workaround. PR1071340: This issue
has been resolved.
•
When inline-sampling is enabled, in race conditions, if packet gets corrupted and the
corrupted packet length shows 0, this may cause "PPE_x Errors thread timeout error"
and eventually cause the MPC card to crash. PR1072136: This issue has been resolved.
•
After IPv6 RPM (real-time performance monitor) support, the SNMP server cannot
receive some of IPv6 PING-MIB info. For example, the SNMP server receives a
"pingCtlRowStatus(23)" and "pingCtlAdminStatus(8)" errors 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
agent at this OID pingProbeHistoryTable(4) SNMPv2-SMI::mib-2.80.1.4 = No Such
Object available on this agent at this OID. PR1072320: This issue has been resolved.
Routing Protocols
•
If with the BGP PIC edge feature enabled and OSPF protocol as IGP, when the primary
route is changed, there is a chance that the Packet Forwarding Engine forwarding entry
will stay in reroute state, which causes session down. PR1015598: This issue has been
resolved.
•
When BGP add-path feature is enabled on the BGP route-reflector (RR) router, and if
the RR router has mix of add-path receive-enabled clients and add-path
receive-disabled (which is default) clients, due to a timing issue, the rpd process on
RR might crash when routes update/withdraw. PR1024813: This issue has been resolved.
•
When a BGP peer goes down, the route for this peer should be withdrawn. If 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 will hardly be experienced.
PR1028390: This issue has been resolved.
•
If labeled BGP routes are leaked from inet.3 table to inet.0, then activation of the BGP
"add-path" feature might crash the routing process (rpd). PR1044221: This issue has
been resolved.
•
230
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
follows: protocols { bgp { bfd-liveness-detection { version 1; minimum-interval 1000;
transmit-interval { minimum-interval 1000; } } } PR1045037: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
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, the running mode of BFD is changed to distributed mode. This behavior is
incorrect but it would not affect protocols that are clients of the BFD session. However,
if Routing Engine switchover is performed after enabling NSR, the BFD session will
become unstable and all the client protocols also become unstable. PR1046755: This
issue has been resolved.
•
On MX Series routers 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: This issue has been resolved.
•
Junos 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 has an "Entry Count" field of zero.
"Entry Count" is a field within the SA message which defines how many source/group
tuples are present within the SA message. PR1052381: This issue has been resolved.
•
Either "rib inet.3" or "resolve-vpn" feature is available to be configured in the lower
hierarchy for BGP labeled-unicast family routes. These two features are mutually
exclusive and only one of them could be used at a single BGP group. If the administrator
swaps the two features (for example, using the "resolve-vpn" first, then deactivate it
and using "rib inet.3" instead, then use "resolve-vpn" back), the secondary routes
(routes in inet.3 which including the ones from this BGP group and from other BGP
groups) may got accidentally removed every time on "commit" operation take place.
PR1052884: This issue has been resolved.
•
After deactivating/deleting a BFD configuration, the Packet Forwarding Engine receives
a BFD session down event and it marks corresponding next hops as down and traffic
drops consequently. PR1053016: This issue has been resolved.
•
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: This issue has been resolved.
•
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: This issue has been resolved.
•
BGP LINK STATE (BGP-LS) was using unofficial code point of '99' for the LINK-STATE
path attribute. Starting with Junos OS Release 14.2R3, BGP-LS uses the 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 unified
ISSU to this version of the code. PR1060162: This issue has been resolved.
•
When running Simple Network Management Protocol (SNMP) polling to specific IS-IS
Management Information Base (MIB) with invalid variable, it will cause routing protocol
process (rpd) crash. PR1060485: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
231
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In PIM environments, Bootstrap Router (BSR) can be used only between PIMv2 enabled
devices. When deactivating all the interfaces that are running PIM bootstrap, the system
changes to operate in PIMv1. At this time, all the information learned about/from the
current BSR should be cleaned, but actually, the 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 there.
When the system tries to access the null BSR timer, the rpd process might crash.
PR1062133: This issue has been resolved.
•
Allow the last 2-byte AS, 65535, to be used as local-as and peer-as, but it will be
considered private in all other regards. PR1069307: This issue has been resolved.
Routing Policy and Firewall Filters
•
RIP route in VRF getting removed once rib-groups are applied with import policy.
PR1024946: This issue has been resolved.
•
In the BGP environment, if operator "!" exists in the regex for as-path, the commit
operation fails. PR1040719: This issue has been resolved.
•
When configuring the unsupported IPv6 flow specification feature, that is, when
configuring the inet6 address as source/destination of the inet-flow route, the
configuration can pass the commit check and being committed. But it can cause the
rpd process to crash eventually when trying to program this route to the 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: This issue has
been resolved.
•
policy displaying is changed and bug fixed PR1060417: This issue has been resolved.
Services Applications
•
The show cli command "service nat pool detail" always displays the Port range starting
from 1024, even when privileged ports are used. PR1019783: This issue has been resolved.
•
Added support to bring up tunnel-switched sessions when tunnel-group is not
configured at LTS and tunnel attributes are returned from RADIUS. PR1030799: This
issue has been resolved.
232
•
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: This issue has been resolved.
•
When using both Port Control Protocol (PCP) and traditional NAT (For example:
DS-Lite), if you try to setup two pools with overlapping address ranges, this can leads
to the MS-DPC to crash and generate a core file. PR1036459: This issue has been resolved.
•
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: This issue has been resolved.
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Inline IPv6 L2TP on MPC subscriber terminated at an LNS breaks adaptive services SP
unicast next hops on the MS-DPC. Even one subscriber causes the issue. PR1054589:
This issue has been resolved.
•
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 the
tunnel negotiation failure. PR1060310: This issue has been resolved.
•
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: This issue has been resolved.
•
When configuring Remote Authentication Dial In User Service (RADIUS) authentication
for Layer 2 Tunneling Protocol (L2TP), the RADIUS server cannot be recognized
becaurse the source address is not being read correctly. As a result, the L2TP session
cannot be established. PR1064817: This issue has been resolved.
•
L2TP daemon will core in an LTS scenario while the subscriber logs out. This happens
when the subscriber has the "Called Number AVP" attribute. The "Called Number AVP"
was not getting relayed correctly across the LTS boundary, hence the daemon cores.
PR1065002: This issue has been resolved.
Subscriber Access Management
•
This issue was introduced as part of another fix. Please contact JTAC for the
recommended release for your deployment. PR1049955: This issue has been resolved.
User Interface and Configuration
•
Customer wants visibility PR1025978: This issue has been resolved.
VPNs
•
On MX-VC platforms, if with a scaled number of MVPN routes, after adding a new
interface in the MVPN instance or changing the traceoptions with related configuration,
the CPU on the Routing Engine might experience a high utilization for about 10 minutes.
PR1027596: This issue has been resolved.
•
In NG-MVPN, after the route to C-RP flaps, traffic loss might be seen for a short period
of time. PR1049294: This issue has been resolved.
•
In NG-MVPN scenarios 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
short time, depending on the configuration. This transition will cause packet loss due
to unbinding from one tunnel to the other and back. PR1049352: This issue has been
resolved.
•
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
Copyright © 2016, Juniper Networks, Inc.
233
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
link on MC-LAG members facing towards the CE is changed continually (that is active
to standby and standby to active), in a rare conditions, the traffic might not shift
correctly, and the rpd process might crash. PR1050737
•
In NG-MVPN scenarios, when a source is directly connected to a PE router that is acting
as an RP stops sending the traffic, the PE router 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 scenarios 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 the 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 a 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 the 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
234
•
Class of Service (CoS) on page 235
•
General Routing on page 235
•
Interfaces and Chassis on page 237
•
Layer 2 Features on page 238
•
Layer 2 Ethernet Services on page 238
•
MPLS on page 238
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Platform and Infrastructure on page 239
•
Routing Protocols on page 239
•
Services Applications on page 240
•
VPNs on page 241
Class of Service (CoS)
•
For MX Series routers with DPCs, IQ2 PIC expects Forwarding Class (FC) index in the
cookie from the DPC for packet queuing. For Transit traffic, fc index is coming in cookie
where are for host outbound traffic, and queue number is coming in cookie to IQ2 PIC.
As IQ2 PIC is not aware whether traffic is transit or host outbound, it treats the value
received in cookie as FC value and looks into fc_to_q table to fetch the queue number.
This is causing an 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 the same. PR1033572
General Routing
•
"show services accounting usage" doesnt populate cpu utilization for XLP based cards
. Please use "show services service-sets cpu-usage" PR864104
•
If the connection with an OpenFlow controller goes down then comes back up
repeatedly, an OpenFlow interface on a QFX5100 switch might send an OFPT_ERROR
packet with an XID ID 0 but no data to explain why the error packet was sent. PR1003538
•
On MPC5, MPC6, MIC6-10G, and MIC6-100G line cards, in order to increase the resiliency
of the system, changes have been made to monitor board voltage levels and ASIC
currents periodically against the expected values, and update current threshold values
as per updated values provided by HW group. PR1004431
•
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
•
Enabling sampling on an ms- interface is not supported. If 'forwarding-options sampling
sample-once' is subsequently deactivated, the FPC may reboot. PR1021946
•
Log Message "MQCHIP(0) mqchip_get_q_forwarded_stats() invalid q_sys 0 q_num "
are continously shown in logs. It will cause two GE or XGE interfaces to not forward
traffic. PR1021951
•
On TXP-3D platform, the chassisd process may hang in scenarios where an FPC restarts
twice, one happening gracefully and the other ungracefully (due to reasons like panic,
bad voltage etc). It will cause interfaces on this FPC down. PR1025732
•
On multiple Routing Engines system with NSR enabled, performing GRES when an
FPC is in the middle of restarting might cause the traffic to this FPC dropped
permanently. PR1026214
•
In ALG environment, the MS-MPC might crash with significant ftp/tftp/http/dns/nat
traffic. PR1026562
•
On MPC5E line card, if a firewall filter with large-scale terms (more than 1300 etc.) is
attached to an interface, traffic drop might be seen. PR1027516
Copyright © 2016, Juniper Networks, Inc.
235
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
In Virtual Private LAN Service (VPLS) scenario with multicast traffic flowing, if the
core-facing interface which is used to reach remote PE is hosted on Dense Port
Concentrator (DPC) card and also the forwarding topology that is using unilist nexthop
(The unilist is a list of nexthops and is used when router want to forward to one of the
component nexthops. It is mostly used for load balancing among the multiple members.
For example, a topology where VPLS PW is loadbalanced using a unilist over an
aggregate Ethernet interface), the composite-nexthop might not be installed on the
DPC card due to the Layer 2 forwarding information getting populated only for the first
unicast nexthop. This issue will result in the multicast traffic drop on the egress DPC.
PR1027827
•
For Trio-based line cards, FPC memory exhaustion or memory churn might lead to FPC
crash. PR1028066
•
Inline BFD sessions, through AE interface when only member interface of the AE is
hosted on MX MPC4E line card, might flap continuously. PR1029341
•
In a rare case, rdd core is reported under /usr/sbin/rdd as soon as applying the group
and commit is performed. PR1029810
•
PCS statistics counter is now displayed for PTX 100GE interfces in below command:
cli > monitor interface <intf> PR1030819
•
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, which 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
236
•
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 scaled environment, the HTTP redirects might stop working while receiving continues
HTTP traffic. PR1032392
•
On MX Seriesplatforms with MPC5/MPC6 installed, in rare cases, a software bug that
will cause Uninitialized EDMEM Read Errors (Uninitialized EDMEM Read Error, there
could be various triggers. It may occur in a transient state (like during config change),
or in a consistent state), the Uninitialized EDMEM Read Errors will trigger fatal CM error
that will result in line card reboot (the default action of fatal CM error). PR1032958
•
During an in-service software upgrade (ISSU), if the ISSU aborts after upgrading backup
Routing Engine (RE) to the new release, it is possible that the backup RE fails to decode
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
the message from the master RE which is running the old release, causing the ksyncd
process crash on backup RE and vmcores (live core) generated on both REs. The master
RE will not be upgraded and the backup RE will remain with the new release. There is
no rollback to old release. We have to manually bring backup RE to old release.
PR1035777
•
In previous versions, a detection mechanism is added for FPC, when single RKME_INT
error is encountered, the FPC will be restarted. Now, the behavior is changed, so that
the FPC will not be restarted when the error occurs. PR1036506
•
Sometimes AE vlan ifl output byte counters are shown as large value and it is a generic
issue. PR1036813
•
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
•
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 PFE 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
Interfaces and Chassis
•
With vrf-table-label configured on the routing-instances, when an FPC with Enhanced
IQ (IQE) PIC is sharing the same Forwarding Engine Board (FEB) with another FPC,
and the FEB has two core-facing interfaces configured with the family mpls on the
aforementioned FPCs separately, the label-switched interface (LSI) might be removed
incorrectly on the working FPC when the other FPC with IQE PIC is set to offline.
PR1027034
•
PTX with 2x100Gig PIC might return incorrect values for
jnxOtnIntervalOtuFec15minCorrectedErrors and
jnxOtnCurrentOtuFec15minCorrectedErrors. This is happening because 2x100Gig PIC
is not supporting jnx-otn.mib. Instead please use jnx-ifotn.mib or jnx-bl.mib. With this
fix, the jnx-otn.mib should not return anything on 2x100Gig PIC. $ snmpwalk -v 2c -Obs
-c public [IP address] jnxOtnIntervalOtuFec15minCorrectedErrors
jnxOtnIntervalOtuFec15minCorrectedErrors = No Such Instance currently exists at this
OID $ snmpwalk -v 2c -Obs -c public [IP address]
jnxOtnCurrentOtuFec15minCorrectedErrors jnxOtnCurrentOtuFec15minCorrectedErrors
= No Such Instance currently exists at this OID On 4x100Gig PIC using jnx-otn.mib for
jnxOtnIntervalOtuFec15minCorrectedErrors and
jnxOtnCurrentOtuFec15minCorrectedErrors, the correct values are reported if the error
rate is below 900. Otherwise the CLI values will give us the right data. PR1038577
•
FRR switching time is much higher than 50 ms (e.g., might be 400-900 ms) when
protected links are located on MX Series Gigabit Ethernet enhanced and hardened
MICs (that is the MIC model name ends with -E or -EH, currently, the supported MICs
are MIC-3D-20GE-SFP-E and MIC-3D-20GE-SFP-EH). PR1038999
•
Using PPP authentication with a specifically crafted PAP Authenticate-Request may
cause the Juniper Networks PPP daemon (jpppd) to crash and restart. After PPPoE
Copyright © 2016, Juniper Networks, Inc.
237
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Discovery and LCP phase is successfully negotiated, when the crafted PAP
Authenticate-Request is received, jpppd crashes and no response is sent by the
broadband edge router to the subscriber. The jpppd continues to crash every time the
subscriber re-sends the PAP Authenticate-Request. Refer to JSA10665 for more
information. PR1040665
•
For Ethernet OAM/CFM, if maintenance-association (MA) ICC format name of length
less than 13 characters (13 bytes) is used, deactivate/activate of “protocol oam” might
cause CFM operation failures. The 'Cross-connect CCM received’ alarm will be seen.
There can be other triggers also. ITU CARRIER CODE format uses fixed length size for
MA NAME (13 octets). Junos OS creates and maintains the actual size configured by
user. However, the length it maintains is 13 octets. For lower the size MA name, the
value accessed is not deterministic. It would work fine if the subsequent memory is
initialized to zero. Otherwise, it will declare cross-connect error as the accessed MA
name to be different compared to the remote end. PR1041482
Layer 2 Features
•
LDP-VPLS with BGP autodiscovery stays down after GRES event when NSR is enabled.
PR1046887
Layer 2 Ethernet Services
•
With Link Aggregation Control Protocol (LACP) enabled for aggregated Ethernet (AE)
bundles, in rare cases, the interface add message for an old logical interface (IFL) exists
in queue that has not got destroyed, while processing this, the old IFL does not exists
and it leads to lacpd process crash and all AE bundles flap. PR1015989
MPLS
238
•
In scenario of egress-protection using stub-alias advertise mode where Point of Local
Repair (PLR) use 'dynamic-rsvp-lsp' in LDP link protection, if protected PE get isolated,
unexpected packet drops will be observed. PR1030815
•
When configuring point-to-multipoint (P2MP) Label Distribution Protocol (LDP)
label-switched paths (LSPs), the labels will never be freed even though they are no
longer needed. This could lead to MPLS label exhaustion eventually. To clear the state,
the rpd process will restart with core files. PR1032061
•
When an LDP-enabled router receives an LDP label mapping message that includes
an unknown TLVs with an unknown and forward bit set, the unknown TLV will be
re-advertised along with the LDP message to the upstream LSR. However, due to a
merge issue, Junos OS appends these unknown TLVs multiple times during construction
of the label mapping message and will have an unknown TLV(0x0000) with length
0 among the appended unknown TLVs. This causes the LDP session with the peer that
receives this message to flap. PR1037917
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
Platform and Infrastructure
•
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 this may impact billing. PR886222
•
All inline-services do not work for high MPC slot numbers on MX2020. It is due to generic
issue in receiving packets. The egress Packet Forwarding Engine instance was chosen
incorrectly. PR1012222
•
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 learned for more than 32 times. PR1026879
•
The commit synchronize command fails because the kernel socket gets stuck.
PR1027898
•
Junos OS reserves the prefix "junos-" for the identifiers of configurations defined within
the junos-defaults configuration group. User-defined identifiers cannot start with the
string "junos-". Due to a defect, prior to Junos OS Release 13.3R1, if you configured
user-defined identifiers through the CLI using the reserved prefix, the commit would
incorrectly succeed. This issue is fixed in 13.3R1 and above releases, configurations that
currently contain the reserved prefix for user-defined identifiers other than
junos-defaults configuration group identifiers will now correctly result in a commit
error in the CLI. But these different behaviors will block software upgrade from Junos
OS release before 13.3R1 to Junos OS release 13.3R1 or later. With the new fix, the
behavior would be changed to display a warning when a reserved identifier is configured.
But commit would go through as shown below: user@router# set applications
application junos-tcp protocol tcp warning: Modifying reserved identifier junos-tcp is
deprecated [edit] user@router# commit commit complete PR1032119
•
Port-Scheduler:Queues are starving with Scheduler on egress port in WAN-PHY mode
PR1035988
•
On Trio-based platform, when using inline Two-Way Active Measurement Protocol
(TWAMP) server (the server address is the inline service interface address), because
the TWAMP server may incorrectly calculate the packet checksum, the packet may
get dropped on the TWAMP client. PR1042132
•
For Junos OS version 13.3R5, if an IPv6 firewall (FW) filter has matching condition 'from
payload-protocol' or 'from payload-protocol-except', and the FW filter is applied on
DPC card interface or loopback interface, the 'from payload-protocol' statement might
be ignored and resulting in the IPv6 FW filter not working well. PR1049590
Routing Protocols
•
In Protocol Independent Multicast (PIM) environment, during processing assert event,
routing protocol process (rpd) crash may occur while getting into situation where there
is no SG node but there is assert state present. PR907797
•
If with accounting/sampling enabled, an unnecessary update from the routing protocol
process (rpd) to the route record database might be triggered by certain configuration
Copyright © 2016, Juniper Networks, Inc.
239
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
change. This process causes jump in CPU utilization of all Packet Forwarding Engines.
PR1002107
•
When policy LFA is being used and backup path selection is first based on the
root-metric criteria, the root-metric should be taken from the link metric connecting
source to the backup neighbor (the one-hop neighbor or a remote router such as an
RSVP backup LSP tail-end router), but it is now taken from the shortest-path-first
(SPF) metric from source to backup neighbor if root-metric highest is configured. In
some topologies, if the two metrics are different, IS-IS might select incorrect backup
next-hop. PR1031408
•
When "clear bfd session" is issued immediately (before the Poll - Final sequence is
completed) post config check-in for interval change from higher to lower
minimum-interval value, BFD sessions don't revert to lower interval. PR1033231
•
OpenSSL released a Security Advisory on 15 Oct 2014 that included CVE-2014-3566
known as the "POODLE" vulnerability. The SSL protocol 3.0 (SSLv3) uses
nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers
to obtain cleartext data via a padding-oracle attack. OpenSSL has been upgraded to
0.9.8zc (pre-Junos OS 13.3) and 1.0.1j (Junos OS 13.3+), adding support for SSL 3.0
Fallback protection (TLS_FALLBACK_SCSV). Refer to JSA10656 for more information.
PR1033938
•
The micro BFD sessions won't come up if incoming untagged micro BFD packets contain
a source MAC where the last 12 bits are zero. PR1035295
•
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
•
Issue in populating isisRouterTable values. Some entries are not filled correctly. This
does not block/affect the functionality of ISIS or other components. PR1040234
•
Junos: RPD cores on receiving a crafted L2VPN family BGP update (CVE-2016-1270).
Refer to https://kb.juniper.net/JSA10737 for more information. PR1041189
•
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
Services Applications
240
•
In L2TP scenario, when the LNS is flooded by high rate L2TP messages from LAC, the
CPU on RE might keep too busy to bring up new sessions. PR990081
•
The cause of the kmd crash is not known. This is not due to SA(Security Associations)
memory corruption. The code looks that SA is getting freed without clearing the table
entry. PR1036023
•
On MX Seriesplatform, when using the MS-DPC with MPSDK to support Captive Portal
Content Delivery (cpcd) service, the MAC may get stuck on the FPC due to processing
the high rate of packets (for example, 5kpps HTTP traffic). In addition, reloading the
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
affected FPC may only temporarily resolve the issue while it will appear again once
scaling up. PR1037143
VPNs
Related
Documentation
•
Problem Description The problem is that MSDP is periodically polling PIM for S,G's to
determine if the S,G is still active. This check helps MSDP determine if the source is
active and therefore the SA still be sent. There is a possibility that PIM will return that
the S,G is no longer active which causes MSDP to remove the MSDP state and notify
MVPN to remove the Type 5. One of the checks PIM makes is to determine if it is the
local RP for the S,G. During a re-configuration period where any commit is done, PIM
re-evaluates whether it is a local RP. It waits until all the configuration is read and all
the interfaces have come up before making this determination. The local rp state is
cleared out early in this RP re-evaluation process, however, which allows for a window
of time where the local RP state was cleared out but it has not yet been re-evaluated.
During this window PIM may believe it is not the local rp and return FALSE to MSDP
for the given source. If MSDP makes the call into PIM during this window after a
configuration change(commit), then it is possible that the Source Active(Type 5) state
will be removed. Fix The fix will be to clear out the local rp state right before it is
re-evaluated ie after it reads configuration for all interfaces; to not allow any time gap
where it could be inconsistent. PR1015155
•
On MX-VC platform, if there is a scaling number of MVPN routes, after adding a new
interface in the MVPN instance or changing the traceoptions related configuration, the
CPU on RE might experience a high utilization for about 10min. PR1027596
•
Upon receipt of a large set of label blocks containing an updated BGP local preference
(due to configuration changes on IBGP peers), RPD may crash with a NULL pointer
access exception. The crash was triggered by a large number of BGP-VPLS
advertisements with updated BGP local preference values. Refer to JSA10687 for more
information. WARNING:Juniper-Confidential-SIRT-PR:see-external-tab! PR1047437
•
In the VPLS environment with 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 (i.e active to
standby and standby to active), in rare condition, the traffic might not shift correctly,
and the rpd process might crash. PR1050737
•
New and Changed Features on page 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Known Issues on page 121
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
Copyright © 2016, Juniper Networks, Inc.
241
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Documentation Updates
This section lists the errata and changes in Junos OS Release 14.2R7 documentation for
the M Series, MX Series, and T Series.
•
Adaptive Services Interfaces Feature Guide for Routing Devices on page 242
•
Broadband Subscriber VLANs and Interfaces Feature Guide on page 243
•
High Availability Feature Guide for Routing Devices on page 244
•
Monitoring, Sampling, and Collection Services Interfaces Feature Guide for Routing
Devices on page 244
•
MPLS Applications Feature Guide for Routing Devices on page 245
•
Overview for Routing Devices on page 245
•
Release Notes on page 245
•
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide for Routing
Devices on page 246
•
Services Interfaces Configuration Guide on page 246
•
Standards Reference on page 246
•
Subscriber Access Protocols Feature Guide on page 246
•
Subscriber Management Access Network Guide on page 247
•
Subscriber Management Provisioning Guide on page 248
•
Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing
Devices on page 249
•
Tunnel and Encryption Services Interfaces Feature Guide for Routing Devices on page 249
•
User Access and Authorization Feature Guide for Routing Devices on page 249
•
VPNs Library for Routing Devices on page 249
Adaptive Services Interfaces Feature Guide for Routing Devices
•
The following items describe updates for aggregated multiservices (AMS) interfaces
information:
•
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.
•
242
The following information should be added to the “Aggregated Multiservices
Interface” section in the “Understanding Aggregated Multiservices Interfaces” topic:
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
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.
•
The descriptions in the “Options” section of the IPsec protocol statement at the [edit
services ipsec-vpn ipsec proposal proposal-name] and [edit services ipsec-vpn rule
rule-name term term-name then manual direction direction] hierarchy levels fail to state
that the ah and bundle options are not supported on MS-MPCs and MS-MICs on MX
Series routers.
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
Copyright © 2016, Juniper Networks, Inc.
243
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
•
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.”
•
244
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:
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
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).
•
The “Configuring RPM Timestamping” topic failed to mention that RPM timestamping
is also supported on the MS-MPCs and MS-MICs on MX Series routers.
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.
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.
Release Notes
•
The PR928128 was incorrectly included as a known issue in the release notes for the
following Junos OS releases:
•
14.2R1 Release Notes
•
14.2R2 Release Notes
•
14.2R3 Release Notes
•
14.2R4 Release Notes
•
14.2R5 Release Notes
Copyright © 2016, Juniper Networks, Inc.
245
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
This issue was fixed before the 14.2R1 Release.
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.
Standards Reference
•
The Supported Network Management Standards topic incorrectly states that Junos OS
supports mplsL3VpnIfConfTable as part of compliance with RFC 4382, MPLS/BGP
Layer 3 Virtual Private Network (VPN) MIB. Junos OS does not support this table.
Subscriber Access Protocols Feature Guide
246
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
•
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
Copyright © 2016, Juniper Networks, Inc.
247
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
•
The Pseudowire Subscriber Logical Interfaces Overview and Configuring a Pseudowire
Subscriber Logical Interface topics have been updated in Junos OS Release 14.2R6 to
state that VLAN demux interfaces are not supported over pseudowire subscriber logical
interfaces. Earlier versions of these topics omitted this information.
Subscriber Management Provisioning Guide
•
The following topics erroneously include information about the Ignore-DF-Bit VSA
(26-70): “RADIUS Attributes and Juniper Networks VSAs Supported by the AAA Service
Framework,” “Juniper Networks VSAs Supported by the AAA Service Framework”, and
“AAA Access Messages and Supported RADIUS Attributes and Juniper Networks VSAs
for Junos OS.” Junos OS does not support VSA 26-70.
Some versions of the RADIUS dictionary file also erroneously list 26-70 as supported
by the Junos OS.
•
In the Broadband Subscriber Sessions Feature Guide, the show network-access aaa
radius servers command topic includes a table that describes the output fields for the
command. The table entry for the Status field does not clearly explain when a request
starts and ends.
The following information has been added to the NOTE in that table entry:
For the purpose of marking a server as Down (DEAD), the request includes the original
request and any retries that are configured. The 10-second timeout period starts after
the initial request and all retries have expired without receiving a response from the
server.
The amount of the timeout period that elapses before the server is marked Down is
not always exactly 10 seconds, and can vary depending on how frequently subscribers
are logging in. When subscribers are continually and rapidly logging in, the server is
marked as Down at 10 seconds. However, if subscribers are logging in less frequently
and at a slower pace, then the server is not marked Down until a subsequent subscriber
attempts to log in. For example, if the subsequent subscriber logs in a minute after the
request and all retries lapse, and the 10-second timeout starts, the actual time until
the server is marked Down is 50 seconds after the timeout starts (the one minute
between subscriber login minus the 10-second timeout).
248
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
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
•
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.
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 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Known Issues on page 121
•
Migration, Upgrade, and Downgrade Instructions on page 250
•
Product Compatibility on page 260
Copyright © 2016, Juniper Networks, Inc.
249
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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 250
•
Upgrade and Downgrade Support Policy for Junos OS Releases on page 253
•
Upgrading a Router with Redundant Routing Engines on page 253
•
Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS
Release 10.1 on page 254
•
Upgrading the Software for a Routing Matrix on page 255
•
Upgrading Using Unified ISSU on page 256
•
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and
NSR on page 257
•
Downgrading from Release 14.2 on page 258
•
Changes Planned for Future Releases on page 258
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
250
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
NOTE: Before upgrading, back up the file system and the currently active
Junos OS configuration so that you can recover to a known, stable
environment in case the upgrade is unsuccessful. Issue the following
command:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstalls
Junos OS. Configuration information from the previous software installation
is retained, but the contents of log files might be erased. Stored files on the
routing platform, such as configuration templates and shell scripts (the only
exceptions are the juniper.conf and ssh files) might be removed. To preserve
the stored files, copy them to another system before upgrading or
downgrading the routing platform. For more information, see the Junos OS
Administration Library for Routing Devices.
Copyright © 2016, Juniper Networks, Inc.
251
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
The download and installation process for Junos OS Release 14.2 is different from previous
Junos OS releases.
1.
Using a Web browser, navigate to the All Junos Platforms software download URL on
the Juniper Networks webpage:
http://www.juniper.net/support/downloads/
2. Select the name of the Junos platform for the software that you want to download.
3. Select the release number (the number of the software version that you want to
download) from the Release drop-down list to the right of the Download Software
page.
4. Select the Software tab.
5. In the Install Package section of the Software tab, select the software package for the
release.
6. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.
7. Review and accept the End User License Agreement.
8. Download the software to a local host.
9. Copy the software to the routing platform or to your internal software distribution
site.
10. Install the new jinstall package on the routing platform.
NOTE: We recommend that you upgrade all software packages out of
band using the console because in-band connections are lost during the
upgrade process.
Customers in the United States and Canada, use the following command:
user@host> request system software add validate reboot
source/jinstall-14.2R6.5-domestic-signed.tgz
All other customers, use the following command:
user@host> request system software add validate reboot
source/jinstall-14.2R6.5-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.
•
252
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.
Migration, Upgrade, and Downgrade Instructions
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.
Copyright © 2016, Juniper Networks, Inc.
253
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
254
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
3. After you have configured the router’s main loopback address on each PE router,
delete the multicast VPN loopback address (lo0.x) from all routers.
We also recommend that you remove the multicast VPN loopback address from all
PE routers from other vendors. In Junos OS releases prior to 10.1, to ensure
interoperability with other vendors’ routers in a draft-rosen multicast VPN network,
you had to perform additional configuration. Remove that configuration from both
the Juniper Networks routers and the other vendors’ routers. This configuration should
be on Juniper Networks routers and on the other vendors’ routers where you configured
the lo0.mvpn address in each VRF instance as the same address as the main loopback
(lo0.0) address.
This configuration is not required when you upgrade to Junos OS Release 10.1 and use
the main loopback address as the source address for multicast interfaces.
NOTE: To maintain a loopback address for a specific instance, configure
a loopback address value that does not match the main instance address
(lo0.0).
For more information about configuring the draft-rosen Multicast VPN feature, see the
Multicast Protocols Feature Guide for Routing Devices.
Upgrading the Software for a Routing Matrix
A routing matrix can be either a TX Matrix router as the switch-card chassis (SCC) or a
TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you upgrade
software for a TX Matrix router or a TX Matrix Plus router, the new image is loaded onto
the TX Matrix or TX Matrix Plus router (specified in the Junos OS CLI by using the scc or
sfc option) and distributed to all line-card chassis (LCCs) in the routing matrix (specified
in the Junos OS CLI by using the lcc option). To avoid network disruption during the
upgrade, ensure the following conditions before beginning the upgrade process:
•
A minimum of free disk space and DRAM on each Routing Engine. The software upgrade
will fail on any Routing Engine without the required amount of free disk space and
DRAM. To determine the amount of disk space currently available on all Routing Engines
of the routing matrix, use the CLI show system storage command. To determine the
amount of DRAM currently available on all the Routing Engines in the routing matrix,
use the CLI show chassis routing-engine command.
•
The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC)
and all LCCs connected to the SCC or SFC are all re0 or are all re1.
•
The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC)
and all LCCs connected to the SCC or SFC are all re1 or are all re0.
•
All master Routing Engines in all routers run the same version of software. This is
necessary for the routing matrix to operate.
•
All master and backup Routing Engines run the same version of software before
beginning the upgrade procedure. Different versions of the Junos OS can have
incompatible message formats especially if you turn on GRES. Because the steps in
Copyright © 2016, Juniper Networks, Inc.
255
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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.
256
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM
and NSR
Junos OS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the
following PIM features are not currently supported with NSR. The commit operation fails
if the configuration includes both NSR and one or more of these features:
•
Anycast RP
•
Draft-Rosen multicast VPNs (MVPNs)
•
Local RP
•
Next-generation MVPNs with PIM provider tunnels
•
PIM join load balancing
Junos OS Release 9.3 introduced a new configuration statement that disables NSR for
PIM only, so that you can activate incompatible PIM features and continue to use NSR
for the other protocols on the router: the nonstop-routing disable statement at the [edit
protocols pim] hierarchy level. (Note that this statement disables NSR for all PIM features,
not only incompatible features.)
If neither NSR nor PIM is enabled on the router to be upgraded or if one of the unsupported
PIM features is enabled but NSR is not enabled, no additional steps are necessary and
you can use the standard upgrade procedure described in other sections of these
instructions. If NSR is enabled and no NSR-incompatible PIM features are enabled, use
the standard reboot or ISSU procedures described in the other sections of these
instructions.
Because the nonstop-routing disable statement was not available in Junos OS Release
9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to
be upgraded from Junos OS Release 9.2 or earlier to a later release, you must disable
PIM before the upgrade and reenable it after the router is running the upgraded Junos
OS and you have entered the nonstop-routing disable statement. If your router is running
Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR
or PIM–simply use the standard reboot or ISSU procedures described in the other sections
of these instructions.
To disable and reenable PIM:
1.
On the router running Junos OS Release 9.2 or earlier, enter configuration mode and
disable PIM:
[edit]
user@host# deactivate protocols pim
user@host# commit
2. Upgrade to Junos OS Release 9.3 or later software using the instructions appropriate
for the router type. You can either use the standard procedure with reboot or use ISSU.
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:
Copyright © 2016, Juniper Networks, Inc.
257
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[edit]
user@host# set protocols pim nonstop-routing disable
user@host# activate protocols pim
user@host# commit
Downgrading from Release 14.2
To downgrade from Release 14.2 to another supported release, follow the procedure for
upgrading, but replace the 14.2 jinstall package with one that corresponds to the
appropriate release.
NOTE: You cannot downgrade more than three releases. For example, if your
routing platform is running Junos OS Release 11.4, you can downgrade the
software to Release 10.4 directly, but not to Release 10.3 or earlier; as a
workaround, you can first downgrade to Release 10.4 and then downgrade
to Release 10.3.
For more information, see the Installation and Upgrade Guide.
Changes Planned for Future Releases
•
Introduction of the all keyword to prevent accidental execution of certain clear
commands—The all keyword is introduced in Junos OS Release 14.2 (as an optional
keyword) and is planned to be introduced in Junos OS Release 15.2 (as a mandatory
keyword) for certain clear commands that are used for clearing protocol and neighbor
sessions. This makes users explicitly select the all keyword to clear all protocol or
session information. Thus, it prevents accidental clearing or resetting of protocols or
neighbor sessions, which might disrupt network operations.
The all keyword is planned to be introduced for the following clear commands:
258
•
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
Copyright © 2016, Juniper Networks, Inc.
Migration, Upgrade, and Downgrade Instructions
•
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:
user@host> clear mpls lsp ?
Possible completions:
<[Enter]>
Execute this command
all
Reset 'all' the nontransit or egress LSPs
originating on this router
<<<<<<<<<<<<
autobandwidth
Clear LSP autobandwidth counters
logical-system
Name of logical system, or 'all'
name
Regular expression for LSP names to match
optimize
Perform nonpreemptive optimization computation now
...
Both clear mpls lsp or clear mpls lsp all will function identically in these releases.
In Junos OS Release 15.2 and later—The all keyword 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.
user@host> clear mpls lsp ?
Possible completions:
all
Reset 'all' the nontransit or egress LSPs
originating on this router
<<<<<<<<<<<<
autobandwidth
Clear LSP autobandwidth counters
logical-system
Name of logical system, or 'all'
name
Regular expression for LSP names to match
optimize
Perform nonpreemptive optimization computation now
...
Related
Documentation
•
New and Changed Features on page 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Known Issues on page 121
Copyright © 2016, Juniper Networks, Inc.
259
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
Documentation Updates on page 242
•
Product Compatibility on page 260
Product Compatibility
•
Software Compatibility on page 260
•
Hardware Compatibility on page 260
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
260
•
New and Changed Features on page 65
•
Changes in Behavior and Syntax on page 104
•
Known Behavior on page 119
•
Known Issues on page 121
•
Documentation Updates on page 242
•
Migration, Upgrade, and Downgrade Instructions on page 250
Copyright © 2016, Juniper Networks, Inc.
Junos OS Release Notes for PTX Series Packet Transport Routers
Junos OS Release Notes for PTX Series Packet Transport Routers
These release notes accompany Junos OS Release 14.2R7 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 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Resolved Issues on page 274
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
New and Changed Features
This section describes the new features and enhancements to existing features in Junos
OS Release 14.2R7 for the PTX Series.
•
Hardware on page 262
•
Class of Service (CoS) on page 263
•
Interfaces and Chassis on page 263
•
Management on page 266
•
MPLS on page 266
•
Multicast on page 266
•
Network Management and Monitoring on page 266
•
Routing Policy and Firewall Filters on page 267
•
Routing Protocols on page 268
•
Software Installation and Upgrade on page 268
•
User Interface and Configuration on page 268
Copyright © 2016, Juniper Networks, Inc.
261
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
•
262
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.
New and Changed Features
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.]
•
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.
263
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
•
264
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.
New and Changed Features
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).]
Copyright © 2016, Juniper Networks, Inc.
265
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.]
266
Copyright © 2016, Juniper Networks, Inc.
New and Changed Features
•
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.]
•
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.
•
Support for logical queue-depth in the PFE for IP options packets for a given protocol
(PTX Series)—Starting with Junos OS Release 14.2R6, you can configure logical
queue-depth in the PFE for IP options packets for a given protocol. The queue-depth
indicates the number of IP options packets which can be enqueued in the PFE logical
queue, beyond which it would start dropping the packets.
Copyright © 2016, Juniper Networks, Inc.
267
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
268
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
Copyright © 2016, Juniper Networks, Inc.
Changes in Behavior and Syntax
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.2R7 for the PTX Series.
•
Class of Service (CoS) on page 269
•
ipv6 on page 269
•
Junos OS XML API and Scripting on page 269
•
Network Management and Monitoring on page 269
•
Routing Protocols on page 270
•
User Interface and Configuration on page 270
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.
ipv6
•
IPv6 addresses with padded zeros in MIC or MS-MPC system log messages (PTX
Series)—Starting with Junos OS Release 14.2R4, all system log messages originating
from MIC or MS-MPC line cards displays 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.
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.
Copyright © 2016, Juniper Networks, Inc.
269
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
[See MIB2D_COUNTER_DECREASING.]
•
Enhancement for SONET interval counter (PTX 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.]
Routing Protocols
•
Modification to the default BGP extended community value (PTX Series)—Starting
in Release 14.1, Junos OS has modified the default BGP extended community value
used for MVPN IPv4 VRF route import (RT-import) to the IANA-standardized value.
The default behavior has changed such that the behavior of the mvpn-iana-rt-import
statement has become the default. The mvpn-iana-rt-import statement is deprecated
and 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).
•
New warning message for the configurational changes to extend-size (PTX
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.
270
Copyright © 2016, Juniper Networks, Inc.
Known Behavior
Related
Documentation
•
New and Changed Features on page 261
•
Known Behavior on page 271
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
Known Behavior
This section contains the known behavior, system maximums, and limitations in hardware
and software in Junos OS Release 14.2R7 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 271
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 261
•
Changes in Behavior and Syntax on page 269
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
Known Issues
This section lists the known issues in hardware and software in Junos OS Release 14.2R7
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 272
•
Class of Service (CoS) on page 272
•
Infrastructure on page 272
•
Interfaces and Chassis on page 272
Copyright © 2016, Juniper Networks, Inc.
271
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
MPLS on page 273
•
Routing Protocols on page 273
General Routing
•
The IFL count is incorrect and will not be repaired until a PIC restart. PR882406
•
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 are rewritten
on the egress MPLS frame following the default EXP rewrite profile. There is no
workaround. PR976481
•
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
•
On FPC3, strict priority mode scheduling may not be accurate with large packet sizes.
PR1099387
•
Traffic may drop during Routing Engine switchover. PR1164107
Class of Service (CoS)
•
In case of member links of an AE (aggregated Ethernet) interface scatter over multiple
Packet Forwarding Engines, if the FPC where member links of the AE interface reside
gets reset or interface is disabled, there may be a dip in the output of SNMP walk on
AE related queue MIB (such as jnxCosQstatTxedPkts). The behavior is intermittent
and not seen every time. PR1122343
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
272
•
During an Routing Engine 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 OS install with the fix to PR
937774 is rebooted. This problem will not be observed during the upgrade to this Junos
Copyright © 2016, Juniper Networks, Inc.
Known Issues
OS install. It occurs late enough in the shutdown procedure then it shouldn't interfere
with normal operation. PR956691
•
On dual Routing Engine platforms, when adding the logical interfaces (IFLs) and
committing, due to the device control process (dcd) on the backup Routing Engine
might fail to process the configuration and keep it in the memory. In some cases (not
happening all the time), it might be observed that the memory of the dcd keeps
increasing on the backup Routing Engine. PR1014098
•
During subscriber login/logout, the following error log might occur on the device
configured with GRES/NSR: /kernel: if_process_obj_index: Zero length TLV! /kernel:
if_pfe: Zero length TLV (pp0.1073751222) PR1058958
MPLS
•
Delay in showing LDP traffic statistics for any particular route; e.g., show ldp
traffic-statistics | grep "101.0.1.0/" takes couple of minutes to throw the output.
PR1077587
•
In an 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, the deletion of
the old sub-LSP might result in deletion of both sub-LSPs. PR1132050
Routing Protocols
Related
Documentation
•
When we have two paths for the same route, the route gets pointed to Unilist NH which
in turn 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 of 3 as opposed to 100 ms with
a multiplier of 3. PR1119253
•
New and Changed Features on page 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
Copyright © 2016, Juniper Networks, Inc.
273
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
•
Resolved Issues: 14.2R7 on page 274
•
Resolved Issues: 14.2R6 on page 275
•
Resolved Issues: 14.2R5 on page 276
•
Resolved Issues: 14.2R4 on page 279
•
Resolved Issues: 14.2R3 on page 279
•
Resolved Issues: 14.2R2 on page 281
Resolved Issues: 14.2R7
•
Forwarding and Sampling on page 274
•
General Routing on page 274
•
MPLS on page 275
•
Platform and Infrastructure on page 275
•
Routing Protocols on page 275
Forwarding and Sampling
•
SRRD (Sampling Route-Record Daemon) process doesn't delete routes when the
DELETE is received from RPD in few configuration cases. This results in build-up of
memory in SRRD daemon and once SRRD reaches the limit, it crashes and restarts
itself. This happens only when one certain family is not configured on all of the FPC
clients (e.g., FPC with inline jflow enabled or PIC with PIC-based sampling enabled is
one client). For example, only IPv4 family is configured in all the clients, and IPv6 and
MPLS families are not configured for sampling in any of the clients. PR1180158
General Routing
•
The FPC on PTX router might crash and reboot when the Packet Forwarding Engine is
handling a fatal error; when the error happens, "TQCHIP0: Fatal error pqt_min_free_cnt
is zero" log message will be seen. PR1084259
•
If a static or protocol learned 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
•
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 unified ISSU (it will be hit if this fix not available in the from build).
PR1155936
•
274
As per design, whenever configuration is committed in PTX3000 platform, chassisd
tries to bring the offline SIBs online. The SIB might not have power because of hardware
issues (such as seen in this scenario where the SIB couldn't be brought online because
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
of a voltage rail failure). In such cases, software shouldn't try to online the SIB. This
attempt is resulting in the software state for this SIB getting stuck in "transition" state
thereby resulting in all future offline/online commands to not take effect on this SIB.
Fixed software to check if there are any hard errors on that SIB before trying to bring it
online. Fix comes in 14.2R7, 15.1F5-S2, 15.1F6, 15.1R4, and 16.1R1. PR1161110
•
For PTX routers, the IPv6 unilist next-hop member will become "replaced" status on
Packet Forwarding Engine (PFE) after interface flapping with IPv6 ND (Neighbor
Discovery) timeout. While the problem is happening, routing-table will display all right
next-hop status but cannot forward traffic since forwarding next-hop in Packet
Forwarding Engine is in "replaced" status and no longer active. PR1177023
MPLS
•
In P2MP with NSR scenario, it might be observed about 100 ms traffic loss during
Routing Engine switchover in steady state with link protection enabled. It is because
the nexthops added by applications in the backup Routing Engine do not match
nexthops fetched from kernel. This nexthops mismatch causes LSPs to reestablish
after switchover. PR1095488
Platform and Infrastructure
•
In certain cases, with some events such as disable/enable of links followed by Routing
Engine rebooting or GRES enabled switchover, below error message could be seen
due to a software bug where it doesn't handle an internal flag properly: “KERNEL/Packet
Forwarding Engine APP=NH OUT OF SYNC: error code 1 REASON: invalid NH add
received for an already existing nh ERROR-SPECIFIC INFO:” PR1107170
•
Configuring one group with configuration of routing-instances and applying this group
under routing-instances, then the rpd process will crash after executing
"deactivating/activating routing-instances" commands. As a workaround, you can
avoid using "apply-groups" under routing-instances hierarchy. PR1109924
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
Resolved Issues: 14.2R6
•
Class of Service (CoS) on page 276
•
General Routing on page 276
•
High Availability (HA) and Resiliency on page 276
•
Routing Protocols on page 276
•
VPNs on page 276
Copyright © 2016, Juniper Networks, Inc.
275
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
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
High Availability (HA) and Resiliency
•
With NSR enabled on multiple Routing Engine systems, when a dynamic GRE tunnel
is configured, performing Routing Engine switchover might causing rpd to crash
repeatedly on backup the Routing Engine. 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
276
•
General Routing on page 277
•
Interfaces and Chassis on page 278
•
MPLS on page 278
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
•
Network Management and Monitoring on page 279
•
Platform and Infrastructure on page 279
•
Routing Protocols on page 279
•
Software Installation and Upgrade on page 279
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
•
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
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
Copyright © 2016, Juniper Networks, Inc.
277
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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
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, user@re0# set interfaces
et-0/0/1 per-unit-scheduler vlan-tagging unit 0 <<<<< The configuration for interface
et-0/0/1 user@re0# commit check error: per-unit-scheduler is configured but
class-of-service is blank <<<<< This is correct behavior error: configuration check-out
failed <<<<< .. user@re0# set class-of-service forwarding-classes queue 7 q7 <<<<<
user@re0# 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
278
•
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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 Packet Forwarding Engine 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
•
General Routing on page 279
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
Copyright © 2016, Juniper Networks, Inc.
279
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
280
•
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,
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
Copyright © 2016, Juniper Networks, Inc.
Resolved Issues
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
•
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
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
Copyright © 2016, Juniper Networks, Inc.
281
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
•
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
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
282
•
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 - user@host#
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 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
Copyright © 2016, Juniper Networks, Inc.
Documentation Updates
Documentation Updates
There are no outstanding issues with the published documentation for Junos OS Release
14.2R7 for the PTX Series.
Related
Documentation
•
New and Changed Features on page 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Migration, Upgrade, and Downgrade Instructions on page 283
•
Product Compatibility on page 286
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 283
•
Upgrading a Router with Redundant Routing Engines on page 283
•
Basic Procedure for Upgrading to Release 14.2 on page 284
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.
Copyright © 2016, Juniper Networks, Inc.
283
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
3. After making sure that the new software version is running correctly on the backup
Routing Engine, switch over to the backup Routing Engine to activate the new software.
4. Install the new software on the original master Routing Engine that is now active as
the backup Routing Engine.
For the detailed procedure, see the Installation and Upgrade Guide.
Basic Procedure for Upgrading to Release 14.2
When upgrading or downgrading Junos OS, use the jinstall package. For information
about the contents of the jinstall package and details of the installation process, see the
Installation and Upgrade Guide. Use other packages, such as the jbundle package, only
when so instructed by a Juniper Networks support representative.
NOTE: Back up the file system and the currently active Junos OS configuration
before upgrading Junos OS. This allows you to recover to a known, stable
environment if the upgrade is unsuccessful. Issue the following command:
user@host> request system snapshot
NOTE: The installation process rebuilds the file system and completely
reinstalls Junos OS. Configuration information from the previous software
installation is retained, but the contents of log files might be erased. Stored
files on the router, such as configuration templates and shell scripts (the only
exceptions are the juniper.conf and ssh files), might be removed. To preserve
the stored files, copy them to another system before upgrading or
downgrading the routing platform. For more information, see the Junos OS
Administration Library for Routing Devices.
284
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:
user@host> request system software add validate reboot
source/jinstall-14.2R5.5-domestic-signed.tgz
Copyright © 2016, Juniper Networks, Inc.
285
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
All other customers, use the following command:
user@host> request system software add validate reboot
source/jinstall-14.2R5.5-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 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Product Compatibility on page 286
Product Compatibility
•
286
Hardware Compatibility on page 287
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 261
•
Changes in Behavior and Syntax on page 269
•
Known Behavior on page 271
•
Known Issues on page 271
•
Documentation Updates on page 283
•
Migration, Upgrade, and Downgrade Instructions on page 283
Copyright © 2016, Juniper Networks, Inc.
287
Release Notes: Junos OS Release 14.2R7 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 techpubs-comments@juniper.net. 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.
•
288
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:
user@host> request support information | save filename
To provide a core file to Juniper Networks for analysis, compress the file with the gzip
utility, rename the file to include your company name, and copy it to
ftp.juniper.net/pub/incoming. Then send the filename, along with software version
information (the output of the show version command) and the configuration, to
support@juniper.net. For documentation issues, fill out the bug report form located at
https://www.juniper.net/cgi-bin/docbugreport/.
Copyright © 2016, Juniper Networks, Inc.
289
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
Revision History
20 September 2016—Revision 4, Junos OS Release 14.2R7– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
25 August 2016—Revision 3, Junos OS Release 14.2R7– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
19 August 2016—Revision 2, Junos OS Release 14.2R7– EX Series, M Series, MX Series,
PTX Series, T Series, and Junos Fusion.
11 August 2016—Revision 1, Junos OS Release 14.2R7– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
14 July 2016—Revision 8, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
10 June 2016—Revision 7, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
9 June 2016—Revision 6, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
5 May 2016—Revision 5, Junos OS Release 14.2R6– EX Series, M Series, MX Series, PTX
Series, T Series, and Junos Fusion.
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.
290
Copyright © 2016, Juniper Networks, Inc.
Requesting Technical Support
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.
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.
Copyright © 2016, Juniper Networks, Inc.
291
Release Notes: Junos OS Release 14.2R7 for the EX Series, M Series, MX Series, PTX Series, T Series, and Junos Fusion
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.
292
Copyright © 2016, Juniper Networks, Inc.